Discussion :

[Miles Raymond]

Bonjour !

J'étais déjà venue poser une question ici à propos d'un problème concernant également Excel et VB.Net. Je charge un fichier xls/xlt/xlsx en générant un tabcontrol avec X tabpage ou x représente le nombre de feuilles du fichier. Pour chaque tabPage j'initialise un datagridview dans lequel je charge ma page Excel x.

J'avais posé une question à propos des drivers qui déconnaît ici :

http://www.developpez.net/forums/sho...d.php?t=512411

Mais j'ai actuellement un autre problème pénalisant. Notre programme va charger des fichiers excel qui seront, généralement, crées à l'avance à partir du programme Omnipage (programme de reconnaissance de texte numérisé). Alors qu'un fichier créés par mes soins, par exemple, se charge sans problème, un fichier génerés par Omnipage ne se chargera pas.

Le comportement est le suivant : le programme fonctionne jusqu'à la ligne ou je remplis mon DataSet (DataAdapter.Fill(DataSet). A ce moment le programme ne plante pas, mais l'activité s'arrête, en faisant du debugging, le programme me dit, après cette ligne :

Aucun code source n'a été chargé pour un frame de pile des appels. Le code source ne peut pas être affichés.

Et il me demande si je veux afficher le code machine. En mettant un point d'arrêt juste après ma ligne de remplissage, je constate que le programme n'atteint jamais cette ligne. En faisant un try / catch, j'ai cette exception :

Trop de champs définis.

Seulement si j'ouvre mon fichier problématique et que je l'enregistre à nouveau (ou si je l'enregistre sous un autre nom) il fonctionne à nouveau. Et en vérifiant le avant/après on remarque que la taille du fichier reste la même, donc il ne rogne pas les possibles champs en trop.

Quelqu'un a une idée ? Une parade possible ? Est-ce possible, avant d'ouvrir le fichier, de vérifier ce problème et de le corriger dans le fichier excel ? (file.saveas, ou que sais-je)

Merci.

[Skalp]

Essaye de modifier les paramètres dans la chaîne de connexion.

Je vois que dans cette chaîne, il y a inscrit "Excel 8.0". Peut-être que les fichiers Omnipage sont générés avec des librairies d'une version plus ancienne d'Excel et alors les fichiers ne seraient pas lisibles par connexion OleDB avec ta chaîne actuelle.

Pour commencer, essaye de mettre "Excel 7.0" ?

[Miles Raymond]

Merci pour ta réponse.

L'idée est excellente et me permet d'affirmer qu'il s'agit bien d'un problème de drivers. Après avoir modifié ma ligne ne mettant Excel=5.0 (puisque les drivers 6.0 et 7.0 n'existent pas) le problème est le même. Le drivers "au dessus" est le driver 12.0, c'est à dire celui de Office 2007 ! J'utilise déjà une version de ce driver (avec l'adjonction Excel 12.0 xml) pour les fichiers xlsx et j'ai essayé, pour les xls, d'utiliser le driver 12.0 sans Xml.

...et ça fonctionne. J'ai Office 2007 sur mon poste et dans tous les postes du bureau donc c'est râpé pour le test. Cependant, même si le fichier se charge, c'est ultra-lent et pas uniquement lorsqu'on le charge, également lorsqu'on parcours le dgv... Donc c'est à moitié utilisable.

Je cherche encore une solution parfaite, mais je doute de trouver quelque chose de plus adéquat...

D'autres idées ?

[Skalp]

Le chargement fonctionne mais très lentement quand tu mets Excel 12.0 dans la chaîne de connexion, c'est bien ça ?

Ce sont des données que tu souhaites seulement charger ou mettre à jour ?
Si tu n'as pas besoin de les mettre à jour, il doit y avoir un moyen plus performant de charger les données. Par exemple en convertissant le fichier en CSV.

[Miles Raymond]

BON ! Explications en quelques mots de ma bêtise intégrale :

En utilisant le Driver 12.0 ce que je n'ai pas vu, lorsque ça fonctionnait, c'est qu'en plus d'être très lent, le datagrid contenait une tapée de colonne (dans les 250 je pense). En fait, en fonction du driver, celui-ci limite le nombre de colonne qu'il peut charger. Donc la version 8.0 doit être plus limitée que la version 12.0. Ensuite la lenteur excédante était dûe au fait que je faisait une lecture de chaque colonne présente pour changer la couleur en fonction de la colonne sélectionnée (technique un peu lourde mais nécessaire) donc lorsqu'on avait dans les 250 lignes, ça prenait un temps fou !

Et au final donc, rien à voir avec le Driver. Je pense gardé le 12 qui semble être le plus performant, si au delà des tests il se révèle concluant avec toutes les versions d'office. Mais le vrai problème était le grand nombre de ligne génerés par Omnipage (des centaines de lignes vides) qui s'effaçaient lorsqu'on sauvegardais (même s'il fallait parfois le faire plusieurs fois). Sachant que je n'ai en général besoin que des 50 premières colonnes (en étant très large) j'ai modifié ma requête Excel en :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * from [sheet1$A1:AZ65535]

Et c'est le paradis !

Bonne fin de semaine et encore merci à toi Skalp.