Je rencontre des problèmes très étranges avec la connexion d'OLE DB aux classeurs Excel.

Notre système dispose d'un grand modèle compatible avec les macros Excel (nous avons Excel 2010 et Excel 2016). Parfois, un utilisateur ajoute des images, des graphiques, des onglets, etc. qui génèrent l'erreur Le tableau externe n'est pas au format attendu lorsqu'il tente de lire un onglet masqué du classeur auquel les utilisateurs n'ont pas accès.

Normalement, nous demandons à l'utilisateur de télécharger un nouveau modèle et de refaire le travail sans ajouter d'images.

Récemment, il y a eu de nombreuses occurrences de ce comportement et j'ai tenté d'enquêter sur mon ordinateur de développement. J'ai constaté que je ne pouvais pas ouvrir une connexion au fichier «corrompu» via le site Web pendant le processus de téléchargement de fichier où le fichier est lu dans un flux d'octets et un fichier .xlsm temporaire est créé et ouvert à l'aide d'un OleDbConnection et les données sont lues à partir de un onglet caché.

Rien de ce que j'ai fait au fichier ne l'ouvrirait pour être ouvert via le code hébergé dans IIS. Cela comprend les éléments suivants:

  • Supprimer toutes les images
  • Supprimer tous les onglets sauf l'onglet masqué
  • Afficher l'onglet que nous lisons
  • enregistrer le classeur au format xlsx pour supprimer les macros
  • enregistrez le classeur en tant que classeur 2003 - 2007, puis enregistrez-le dans un fichier xlsx ou xlsm

Le site Web fonctionne sous .NET Framework 4.0 et sous IIS.

Pour mon enquête, j'ai écrit le code suivant et je l'ai hébergé sur l'ordinateur de développement même dans une page d'une application Web de test hébergée dans IIS Express sous .NET Framework 4.0 et il ouvert et lu avec succès les données du fichier d'origine «corrompu».

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.OleDb;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

public partial class ReadExcelTabToDataSet : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        string szSheetName = @"C:\Temp\Test.xlsm";
        string szConnection = "Provider=Microsoft.ACE.OLEDB.12.0;Extended Properties=\"Excel 12.0;HDR=YES\";Data Source=" + szSheetName;

        string szQuery = "Select 'Configuration$' as Sheet, * From [Configuration$B1:S2]";
        string szExcelTableName = "ValidateFlag";
        DataSet ds;

        using (OleDbConnection conn = new OleDbConnection(szConnection))
        {
            using (OleDbDataAdapter da = new OleDbDataAdapter(szQuery, conn))
            {
                conn.Open();
                ds = new DataSet();
                da.Fill(ds, szExcelTableName);
            }
        }
    }
}

Cela soulève beaucoup de cloches d'avertissement et m'a déconcerté. Ce test semble exclure tout sauf comment OleDb fonctionne lorsqu'il est hébergé dans IIS. Lorsque cette page est copiée sur notre site, elle échoue sur le conn.Open ().

Est-ce que quelqu'un comprend pourquoi cela se produit et comment y remédier? Je ne veux pas pénaliser nos utilisateurs pour des problèmes Microsoft étranges comme celui-ci.

Merci,

MODIFIER 1

Si le fichier est marqué "lecture seule" et qu'il se trouve dans un répertoire qui dispose d'un accès complet, le fichier peut être ouvert et les données peuvent être lues avec succès.

Cela pose toujours un problème car nous ouvrons le fichier, vérifions les informations et, enfin, apportons des modifications à l'onglet.

0
Lee Z 20 avril 2017 à 16:33

3 réponses

Meilleure réponse

J'ai commencé à étudier en utilisant ClosedXml (une solution .NET construite autour d'OpenXML) pour surmonter de nombreux problèmes OleDb que je rencontre. Lors de la tentative d'ouverture des classeurs «corrompus» à l'aide de ClosedXml, j'ai reçu un message d'erreur que j'ai pu dupliquer à l'aide du SDK Microsoft Open XML.

La cause du problème est un bouton de formulaire qui exécute le code VBA pour copier les données dans le modèle d'un onglet à un autre. Le texte dans le bouton de formulaire contenait un retour chariot (c'est-à-dire un br). Lorsque la taille du modèle devient grande et que l'utilisateur enregistre son travail, Excel corrompt le HTML en ne mettant pas fin au br. Alors que la commande ACE OleDB ne fournit aucune indication, le SDK Open XML fournit le message suivant:

Impossible d'ouvrir le fichier: Pièce /xl/drawings/vmlDrawing4.vml: La balise de début «br» à la ligne 19 position 29 ne correspond pas à la balise de fin de «font». Ligne 20, position 9.

Si l'extension du modèle est renommée de .xlsm en .zip, le fichier réel peut être inspecté et la cause peut être corrigée. Dans ce cas, j'ai dû supprimer la coupure entre les mots sur le bouton.

Cela me préoccupe qu'Excel devienne instable à mesure que la taille du fichier augmente et n'enregistre pas correctement les classeurs à ce stade, mais je suis capable de contourner ce cas.

0
Lee Z 6 juin 2017 à 13:52

J'ai rencontré le même message d'erreur lors de l'utilisation de la connexion ADO d'un classeur Excel (A) vers un autre classeur Excel (B). Le classeur A est ouvert par un utilisateur et le classeur B est fermé, mais connecté par ADO en mode lecture / écriture.

L'erreur " La table externe n'est pas au format attendu " se produit lorsque le classeur B est mis à jour et enregistré par ADO, mais lorsque le disque est plein .

Les erreurs de disque plein ne doivent pas être courantes et elles sont assez simplement surmontées si le classeur est ouvert par un utilisateur car l'utilisateur est averti et peut enregistrer le classeur dans une autre zone. Cependant, lorsqu'il est ouvert via une connexion ADO, il n'y a pas d'avertissement et donc le classeur (B dans ce cas) ne s'enregistre pas correctement et devient corrompu - du moins c'est ce que j'ai conclu.

Lorsque le classeur B est ensuite ouvert par un utilisateur, un avertissement indique que le classeur est endommagé. Après une tentative de récupération, le classeur apparaît vide. Toutefois, la fermeture du classeur B, puis l'exécution d'une requête SQL sur celui-ci (connexion ADO en mode lecture seule) renvoie parfois des données (en fonction de l'étendue de la corruption), mais les données sont incomplètes.

Je publie ceci dans l'espoir que cela puisse être utile car c'est la même erreur et cela provoque la corruption, bien que par une cause différente du problème de Lee Z. Hélas, ce n'est pas un remède, mais j'espère que c'est instructif.

0
englandexpects 9 janv. 2018 à 07:23

"La table externe n'est pas dans le format attendu" Est une erreur générique qui à cause (malheureusement) pour beaucoup de raisons, Dans mon cas, c'était parce que je n'ai pas déchiffré le fichier correctement.

Mon meilleur pari serait de vérifier votre programme, de le tester avec un tout nouveau fichier et de localiser l'erreur de cette façon.

Bonne chance!

0
Sebastiaan Peters 20 avril 2017 à 13:56