Colonnes ignorées utilisant vb6 pour extraire Excel

Question

J'essaie d'extraire une table de valeurs d'une feuille de calcul Excel (2003) à l'aide de vb6, dont le résultat doit être stocké dans un jeu d'enregistrements (adodb). Le tableau ressemble à ceci:

    Name   Option.1  Option.2  Option.3  Option.4  Option.5  Option.6 
    -----------------------------------------------------------------
    Name1         2         3         4
    Name2         2         3         4
    Name3         2         3         4
    Name4         2         3         4
    Name5         2         3         4
    Name6         2         3         4
    Name7         2         3         4
    Name8         2         3         4
    Name9         2         3         4         5         6         7  

Lors de la connexion et de l'exécution de la requête " SELECT * FROM [Sheet1 $] " ou même une colonne spécifique, " SELECT [option n ° 6] à partir de [Sheet1 $] " (Voir note 1) et en parcourant les résultats, on me donne les valeurs Null de la ligne Nom9 , Option.4 - > Option.6 plutôt que les valeurs correctes 5, 6 et 7. Il semble que la connexion à la feuille de calcul utilise une "meilleure estimation". de décider quelles sont les limites de table valides et ne prend en compte qu'un nombre défini de lignes.

Pour me connecter à la feuille de calcul, j'ai essayé les deux fournisseurs de connexion Microsoft.Jet.OLEDB.4.0 et MSDASQL et le même problème.

Voici les paramètres de connexion que j'utilise:

Set cn = New ADODB.Connection
With cn
    .Provider = "Microsoft.Jet.OLEDB.4.0"
    .ConnectionString = "Data Source=" & filePath & ";Extended Properties=Excel 8.0;"
    - - - - OR - - - - 
    .Provider = "MSDASQL"
    .ConnectionString = "Driver={Microsoft Excel Driver (*.xls)};" & _
                        "DBQ=" & filePath & ";MaxScanRows=0;"
    .CursorLocation = adUseClient
    .Open
End With  
Set rsSelects = New ADODB.Recordset
Set rsSelects = cn.Execute("SELECT [Option#5] FROM " & "[" & strTbl & "]")

Ce problème ne se produit que s'il y a plus de 8 lignes (à l'exclusion des noms de colonnes) et que j'ai défini MaxScanRow = 0 pour la connexion MSDASQL , ce qui a produit les mêmes résultats.

Les références de projets notables que j'ai incluses sont les suivantes:

• Bibliothèque MS ActiveX Data Objects 2.8
• Bibliothèque Recordset 2.8 MS ActiveX Data Objects
• Bibliothèque d'objets MS Excel 11.0
• Collection MS Data Binding 6.0 (SP4)

Toute aide en la matière serait très appréciée!

(1) Pour une raison quelconque, lorsque vous insérez un signe décimal dans le nom de la colonne, celui-ci est interprété comme un #.

Merci à tous! A mi-chemin, essayez de configurer un Schema.ini "par programme". à partir de KB155512 onedaywhen l'excellent post m'a indiqué la solution:

.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "Data Source=" & filePath & ";Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1"";"

J'encourage toute personne ayant des problèmes similaires à lire le post et les commentaires, car il existe de légères variations dans la solution d'une personne à l'autre.

Answer 1

Vous avez raison: il s'agit de deviner le type de données en fonction d'un nombre de lignes. Il est possible de modifier certaines clés de registre d'ordinateur pour influencer le type de données choisi. Pour plus de détails, voir cette réponse .

Answer 2

Par défaut, le pilote Excel ISAM examine la première poignée de vos lignes et en détermine le type de données. S'il devait y avoir (plus tard dans le tableau) des données qui ne correspondent pas à l'hypothèse initiale, il fronce les sourcils et les tourne à NULL.

Votre paramètre MaxScanRows = 0 est la clé de ce problème. On dirait que nous ferions la bonne chose (balayer le tableau entier pour le type de données à utiliser), mais ce n’est vraiment pas le cas.

Voir onedaywhen , réponse de Les détails, mes premières informations sur KB282263 n'étaient pas les bons conseils.

Answer 3

Le meilleur conseil que je puisse vous donner est de cesser de le faire dans l'environnement VB6. Ouvrez Excel, appuyez sur ALT + F11 et chargez l'EDI VBA. Mettez votre code dedans. À partir de cet environnement, vous pouvez accéder au modèle d'objet Excel complet.

J'ai vu beaucoup de gens essayer d'interagir avec Excel de différentes façons et ils ont tous des problèmes. L'utilisation de la macro VBA ou de la méthode du complément est l'un des meilleurs moyens que j'ai trouvé pour obtenir les données. C’est ainsi que Microsoft intègre Excel et Project à l’intégration de TFS.

Parfois, vous devez repenser légèrement le processus pour que cette approche soit appropriée. Par exemple. Vous devrez peut-être demander à l'utilisateur qui utilise la feuille de calcul d'exécuter une macro qui extraira les données de la feuille de calcul à la place d'un processus permettant d'extraire les données de la feuille de calcul, mais cela est généralement tout à fait réalisable.