ODBCDotNet : Extraire des requêtes ODBC dans un
tableau de tableaux de String
Documentation : ODBCDotNet.html
http://patrice.dargenton.free.fr/CodesSources/ODBCDotNet.html
http://patrice.dargenton.free.fr/CodesSources/ODBCDotNet.vbproj.html
https://codes-sources.commentcamarche.net/source/34701
Par Patrice Dargenton : patrice.dargenton@free.fr
http://patrice.dargenton.free.fr/index.html
http://patrice.dargenton.free.fr/CodesSources/index.html
Version 1.12 du 11/12/2011
Voici une
classe pour le requêtage ODBC à vocation universelle : pour cela, on utilise un
fichier .dsn (Database Source Name) externe dans lequel on indique le type de la source
ODBC à interroger (on peut en générer pour de nombreux types de base de données). L'évolution par rapport à la précédente source XLDB que j'avais présenté il y a quelques mois est que
l'on peut maintenant préciser la requête à effectuer aussi dans un fichier
externe .sql, de sorte que l'on s'affranchi de la
spécificité éventuelle de la source, notamment Excel, pour laquelle il faut
ajouter $ à la fin de chaque nom de table (correspondant à chaque feuille
Excel) : on peut donc écrire des requêtes spécifiques à chaque source ODBC sans
avoir à recompiler le programme. De plus, on peut maintenant effectuer une
série de requêtes successives, simplement en séparant les requêtes par un ;
comme dans la syntaxe standard de SQL. Pour pouvoir stocker et renvoyer le
résultat propre à chaque requête, l'astuce consiste à stocker des tableaux 2D
de String dans un tableau conteneur, tout est redimensionné en fonction des
requêtes demandées : il suffit alors d'effectuer le traitement d'analyse en
dehors de la classe ODBC. L'avantage est que le composant d'accès
ODBC gère tout le traitement d'erreur spécifique à ODBC, il ne reste plus qu'à
traiter les conversions de valeurs String en fonction de vos besoins propres,
c'est de l'ETL ! (Extract, Transform
and Load : Extraire, transformer
et charger).
Fonctionnalités :
- Nouveau
: Explorateur de source de données (tables et champs avec leurs types et
tailles) ;
- Utilisation
de fichiers .dsn et .sql
externes ;
- Création d'un fichier .dsn et .sql par défaut pour Access, Excel, Omnis, DB2 (iSeries d'IBM, anciennement AS/400) via le pilote Client Access, et Navision (Microsoft Business Solutions) via le pilote C/ODBC ;
- Vérification
de l'accessibilité effective de la source au moment de l'extraction (pour les
sources de type fichier) ;
- Utilisation
possible d'une chaîne de connexion directe, par exemple sur un fichier
Excel ;
- Gestion
des requêtes multiples séparées par des ";" ;
- Gestion
de requêtes programmées par le code (au lieu du fichier externe .sql) ;
- Fonctionnement
par exemple jusqu'à 254 champs avec le pilote ODBC pour Excel ;
- Avec
Excel, les champs calculés sont bien supportés (les valeurs calculées sont
retournées comme pour les autres champs) ;
- Requête
en écriture si le pilote ODBC le permet ;
- Affichage
d'un pourcentage d'avancement ;
- Interruption
possible si c'est trop long ;
- Copie
des informations dans le presse-papier pour le débogage.
Table des matières
Conversion
des valeurs en chaînes de caractères via ToString
Notes
sur la conversion en nombre réel
Syntaxe
pour l'écriture des critères sur des dates
Version
1.00 du 19/11/2005 : Première version
Les pilotes
ODBC ne dépendent pas des paramètres régionaux de Windows, par contre, dans
ODBCDotNet, la conversion ToString utilise le format
en vigueur dans les paramètres régionaux de Windows, par exemple pour le
séparateur décimal :
sValChamp = oValChamp.ToString
C'est
l'inconvénient d'utiliser un type chaîne unique pour stocker toutes les valeurs
de chaque champ, l'avantage est d'éviter d'avoir à traiter chaque type de
donnée lors de cette étape (pour cela il faudrait ajouter pas mal de code pour
traiter tous les cas).
C'est pour
cela qu'on remplace systématiquement le séparateur décimal utilisé par un
séparateur unique, le point décimal, afin de pouvoir ensuite utiliser les fonctions
de conversions qui ne dépendent plus des paramètres régionaux, et qui sont plus
standards et moins risquées à mon avis. Cette option est toutefois désactivable via le paramètre m_bRemplacerSepDec,
si on préfère faire ce traitement en dehors de la classe ODBC et uniquement sur
les champs numériques.
Comparaison
des fonctions Val et CSng lorsque le séparateur
décimal est , puis .
Conclusion : Val fonctionne dans tous les cas sans lever
d'erreur si on force le point décimal.
? sSepDecimal (=Globalization.NumberFormatInfo.CurrentInfo.NumberDecimalSeparator())
","
? Val("1.1")
1.1
? Val("1,1")
1.0
? CSng("1.1")
1.1
? CSng("1,1")
1.1
? sSepDecimal
"."
? Val("1.1")
1.1
? Val("1,1")
1.0
? CSng("1.1")
1.1
? CSng("1,1")
Exception runtime levée : System.InvalidCastException
- Cast de la chaîne "1,1" en type 'Single'
non valide.
Avantages
et inconvénients de forcer le . dans toutes les valeurs de
champ : en utilisant la fonction Val sur les champs numériques, on obtient donc
toujours la bonne valeur sans jamais lever d'exception, ce qui est rassurant
car on n'a plus besoin de préoccuper des paramètres régionaux de Windows et de retester tout son logiciel à chaque fois, ce qui est
fastidieux. Cependant, les champs non numériques contenant des
, risquent d'être changés intempestivement en . (par
exemple dans la désignation d'un article) : une solution consisterait à
n'effectuer ce remplacement que pour les champs numériques, mais la fonction IsNumeric est épouvantablement lente ! Dans ce cas, il
reste deux autres solutions : lire le schéma de la base de données pour
déterminer les champs numériques à l'avance (voir la fonction bExplorerSourceODBC), ou sinon laisser le séparateur
décimal en vigueur, et traiter uniquement les champs numériques en dehors de la
classe ODBC. Ne pas oublier dans ce cas d'utiliser la fonction CSng et non plus Val, en sachant que CSng
est dépendante de la culture locale.
Si par
ailleurs vous devez importer directement un fichier csv
dans une culture neutre ou internationale, vérifier bien quel est le séparateur
décimal utilisé, car on ne peut pas être sûr que ce sera le point décimal
(possibilité : repasser par un pilote ODBC sur le csv
pour réappliquer la culture locale, ce qui sera sans
doute moins rapide).
Autre
solution possible : utiliser la
fonction TryParse (je n'ai pas encore testé). En
DotNet1, TryParse est limité au type System.Double, tandis que la fonction a été généralisée à
d'autres types en DotNet2.
- C/ODBC : {d 'yyyy-MM-dd'} : DateVente >= {d '2006-01-31'}
- Excel : #yyyy/MM/dd# : DateVente>=#2006/01/31#
- Omnis : 'yyyy/MM/dd' : DateVente>='2006/01/31'
Pour générer un fichier .dsn correspondant à une base dont le pilote ODBC est installé sur votre poste, utilisez l'assistant fourni dans Windows 2000 (et versions supérieures de Windows) :
Panneau de configuration : Outils
d'administration : Sources de données (ODBC) : Sources de données fichier :
Ajouter : Choisissez votre pilote ODBC : Suivant : Choisissez le chemin où
sauver le fichier qui va être créé par l'assistant (ou bien Parcourir : Sélectionnez
un fichier : Enregistrer) : Suivant : Terminer : Base de données :
Sélectionner... : Choisissez le chemin de votre base (si le pilote ODBC
fonctionne ainsi) : Ok pour ce fichier : Ok pour cette base : Ok pour quitter
l'assistant.
Comment
crypter un mot de passe dans le DSN : passer par l'interface de config ODBC de
Windows, générer un fichier DSN et copier/coller ensuite le résultat. Mais
attention : le mot de passe, même crypté, est aussi fonctionnel que le non
crypté, mais au moins il ne peut servir que dans un DSN.
Pour limiter
le risque de sécurité, il faut créer un compte utilisateur avec le minimum des
droits requis pour l'exécution des requêtes indiquées dans le fichier .sql ; ainsi, si un hacker pirate le PC et tombe sur le DSN,
il n'aura que les droits du compte. Si le mot de passe n'est pas crypté, il
pourra l'utiliser pour se loguer directement sur la base de données, sinon, si
le mot de passe est crypté dans le DSN, il pourra quand même utiliser
ODBCDotNet avec ce DSN, et il pourra faire tout ce que le compte utilisateur
peut faire !
Voir ici pour
la lecture des fichiers Excel 2007 via ODBC :
2007 Office System Driver: Data Connectivity Components : AccessDatabaseEngine.exe
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties="Excel 12.0;HDR=YES;IMEX=1";
Et en 64 bits
:
http://blogs.codes-sources.com/coq/archive/2007/11/25/microsoft-ace-oledb-12-0-en-64-bit.aspx
Lorsque
ODBCDotNet ne trouve pas le fichier .dsn, alors il
peut créer un fichier .dsn et .sql
par défaut, si les paramètres correspondants sont précisés dans le code source
(voir le fichier frmODBC.vb). S'il y a déjà un
fichier .dsn, mais pas de fichier .sql, alors un message d'erreur est affiché, à moins qu'une
requête soit codée directement en paramètre de la classe. Les fichiers .dsn sont créés selon un des types suivants, en fonction du
paramètre m_sSQLXxxDef qui est définis.
Consultez les
documentations correspondantes à chaque pilote ODBC, ou bien le
code source d'ODBCDotNet
pour avoir davantage d'informations sur chaque paramètre. Les paramètres à
modifier obligatoirement sont indiqués en gras.
Pour les
chemins, on peut aussi les indiquer en relatif par rapport au dossier où se
situe l'application (en tout cas pour Excel cela fonctionne), par
exemple :
DefaultDir=.\MonDossierSourceODBC
DBQ=.\MonDossierSourceODBC\MonFichierExcel.xls
Si on précise
le dossier de la source par défaut, alors il n'est pas nécessaire de préciser
le chemin complet vers le fichier source :
DefaultDir=.\MonDossierSourceODBC
DBQ=MonFichierExcel.xls
[ODBC]
DRIVER=Microsoft Access Driver (*.mdb)
UID=admin
UserCommitSync=Yes
Threads=3
SafeTransactions=0
PageTimeout=5
MaxScanRows=8
MaxBufferSize=2048
FIL=MS Access
DriverId=25
DefaultDir=C:\Program
Files\MonDossierSourceODBC
DBQ=C:\Program Files\MonDossierSourceODBC\MaBaseAccess.mdb
[ODBC]
DRIVER=Microsoft Excel Driver (*.xls)
UID=admin
UserCommitSync=Yes
Threads=3
SafeTransactions=0
ReadOnly=1 (ou 0
pour le mode écriture)
PageTimeout=5
MaxScanRows=8
MaxBufferSize=2048
FIL=excel 8.0
DriverId=790
DefaultDir=C:\Program
Files\MonDossierSourceODBC
DBQ=C:\Program Files\MonDossierSourceODBC\MonFichierExcel.xls
Attention au
mélange des données numériques et textes dans une même colonne : ce mélange
risque de produire une perte de données car l'extraction ODBC (ou bien une
requête DAO) ne peut pas obtenir simultanément l'un et l'autre des 2 types de
données. Solution : dans Excel, appliquer le format texte à la colonne ET
convertir les données de la colonne via le menu Données : Convertir... en
précisant le format texte (au lieu du format standard) à la troisième et
dernière étape de l'assistant conversion de données, explications :
www.dicks-blog.com/archives/2004/06/03/external-data-mixed-data-types/
Note : lorsque
l'on enregistre le fichier Excel en .csv, Excel
effectue automatiquement cette conversion à ce moment là, ce qui à l'avantage
de concerner toutes les colonnes à risque d'un coup (mais on ne peut convertir
qu'une feuille à la fois).
Description du bug : Excel Values Returned as NULL Using DAO OpenRecordset :
http://support.microsoft.com/kb/194124/EN-US/
Description de la solution :
Format existing numbers as text : Three ways to convert numbers to text :
http://office.microsoft.com/en-us/assistance/HA011366191033.aspx
Ce problème
concerne surtout les versions d'Excel inférieures à 2003, car depuis 2003,
Excel utilise un composant d'accès aux données JET plus fiable. Avant cette
version 2003, le pilote examinait un certain nombre de lignes indiqué par un
paramètre afin de déterminer automatiquement le type du champ à créer afin de
stocker les valeurs de la colonne Excel. Pour le fichier DSN, il s'agissait du
paramètre MaxScanRows, mais en pratique MaxScanRows n'est jamais utilisé ! Seule la clé suivante TypeGuessRows de la base de registre est prise en compte :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel
Pour augmenter
la valeur
par défaut
qui est de 8 seulement, le plus simple consiste à fusionner directement le
fichier ODBCExcelAugmenterTypeGuessRows.reg pour
fixer la valeur à 16384 afin de lire un plus grand nombre de lignes pour
déterminer le type de données capable de stocker les valeurs d'une colonne
Excel, ce qui est nécessaire par exemple si les premières occurrences du champ
sont vides dans la feuille Excel.
La fonction VerifierConfigODBCExcel() vérifie s'il y a ce risque en fonction de la
configuration. Excel 2003 fonctionne bien dans tous les cas, car il utilise une
dll plus efficace :
Microsoft Access Expression Builder
:
C:\Program Files\Microsoft
Office\Office11\msaexp30.dll (11.0.6561.0)
la dll par défaut étant
(sous-clé win32old) : Microsoft Jet Excel Isam :
C:\Windows\System32\msexcl40.dll (4.0.8618.0)
Un autre bug
apparenté pouvait se produire sur l'instruction oRq.MoveNext() au moment de
franchir justement ce fameux nombre de ligne examinée au préalable :
[Microsoft][Pilote
ODBC Excel] Dépassement d'un champ numérique.
Numéro : -2147467259
(80004005) Erreur Jet : S1000
Cette erreur
est en fait assez générique, car on la retrouve pour plusieurs catégories de
problème (voir XLDB). La solution est la même (augmenter la valeur de TypeGuessRows si Excel < 2003), ou bien passer en
connexion directe sans utiliser de DSN (j'ai remarqué que cela pouvait corriger
le problème). Rappel : les paramètres MaxScanRows et ImportMixedTypes sont sans effet pour ce problème, qu'ils soient
utilisés dans la chaîne de connexion directe, ou bien dans le fichier DSN.
Notes :
- La première ligne de chaque feuille Excel à lire doit contenir les en-têtes de colonnes, qui indiqueront alors les noms de chaque champ ; pour une requête en écriture vers Excel, il peut être utile d'ajouter aussi une ligne d'exemple de donnée en plus de l'entête pour forcer le pilote ODBC à adopter le bon type de donnée pour chaque colonne (et pour choisir une présentation différente de la ligne d'entête) ;
- Les caractères
Unicodes sont bien respectés dans Excel via ODBC :
par exemple le mot "cœur" passe correctement ;
- Le
pilote ODBC pour Excel supporte jusqu'à 254 champs sans problème ;
- Si on
force un séparateur décimal différent de celui en vigueur dans les paramètres
régionaux de Windows dans une colonne Excel, alors le type de donnée de la
colonne passe en type texte (Excel ne peut plus traiter directement les valeurs
en numérique, à éviter donc), et l'extraction ODBC se fait alors en type texte,
sans perte de données (et sans risque d'adaptation régionale par ODBCDotNet
cette fois lors de l'instruction ToString) ;
- On peut
saisir des valeurs à la volée dans Excel et faire des requêtes sans avoir à
sauver le fichier (ce qui est impossible avec une vrai base de données), par
contre c'est beaucoup plus lent.
[ODBC]
DRIVER=OMNIS ODBC Driver
UID=admin
Password=MonMotDePasse
Username=MonCompteUtilisateur
DataFilePath=C:\Program
Files\MonDossierSourceODBC\MaBaseOmnis.df1
Téléchargement
du pilote ODBC pour Omnis :
www.omnis.net/downloads/odbc/win32/Omnis%20ODBC%20Driver.exe
Note : Penser à mettre les critères les plus contraignants
en premier.
Voici un exemple d'accès à une base Navision (Microsoft Business Solutions) via le pilote C/ODBC :
[ODBC]
DRIVER=C/ODBC
32 bit
UID=MonCompteUtilisateur
SERVER=N
CN=MonCompteSociete
RD=No
ML=1033
CD=No
BE=Yes
CC=Yes
RO=No
QTYesNo=Yes
IT=All Except Space
OPT=Text
PPath=C:\Program Files\Microsoft Business Solutions-Navision\Client
NType=tcp
SName=MonServeur
CSF=Yes
PWD=MonMotDePasse
Attention : il
n'est pas possible de crypter le mot de passe avec ce pilote : la doc C/ODBC
recommande de créer un compte utilisateur spécifique avec les seuls droits
requis pour l'exécution de la requête.
Le pilote Navision est introuvable sur le net, à ma connaissance, il
ne se trouve que sur le CD d'installation de Navision,
dans le dossier C/ODBC.
Il y a aussi
un paramétrage minimal (à vérifier) :
[ODBC]
DRIVER=C/ODBC
32 bit
UID=MonCompteUtilisateur
SERVER=N
CN=MonCompteSociete
PPath=C:\Program Files\Microsoft Business Solutions-Navision\Database Server
NType=tcp
SName=MonServeur
CSF=Yes
Exemple pour DB2 (iSeries
d'IBM, anciennement AS/400) via le pilote Client Access :
[ODBC]
DRIVER=Client Access ODBC Driver (32-bit)
UID=MonCompteUtilisateur
(ou CA400 par défaut)
DEBUG=64
SIGNON=1
LIBVIEW=1
TRANSLATE=1
NAM=1
DESC=Source de
données ODBC iSeries Access for Windows
SQDIAGCODE=
DATABASE=
QAQQINILIB=
PKG=QGPL/DEFAULT(IBM),2,0,1,0,512
TRACEFILENAME=C:\Documents and
Settings\MonCompteWindows\Mes documents\IBM\Client
Access\Maintenance\Fichiers trace (à vérifier : MonCompteWindows
= 'Utilisateur' littéralement ?)
SORTTABLE=
LANGUAGEID=ENU
XLATEDLL=
DFTPKGLIB=QGPL
DBQ=QGPL (à
vérifier : ici on peut indiquer une autre librairie que la librairie QGPL par
défaut, ce qui permet d'éviter d'avoir à préfixer les noms des tables par la
librairie dans les requêtes SQL)
SYSTEM=MonServeur (ou
adresse IP)
Pour DB2, il
n'y a pas forcément de mot de passe, il faut laisser une connexion ouverte (via
le Client Access) et le pilote ODBC va réutiliser cette connexion (si la
connexion n'est pas ouverte, le système devrait ouvrir une boite de dialogue
pour saisir le mot de passe, mais je n'ai pas réussi à le faire marcher ainsi).
Cependant, on peut aussi préciser le mot de passe avec PWD=MonMotDePasse.
- <PlatformTarget>x86</PlatformTarget>,
voir ici :
Comment
faire fonctionner ODBC avec Windows 64 bits ?
- Mode bLireToutDUnBlocRapide amélioré : les requêtes multiples
sont maintenant possibles (si les requêtes sont de structures identiques) ; Const sDelimiteurLignesRapide$ = vbCrLf ajouté ; Présentation log corrigée : ajout entête
(même présentation que le mode normal) ;
- Passage
en VB 2008.
- Vérification
du mode Excel : Correction auto de TypeGuessRow par
le code.
- Liste
des tables en mode debug presse-papier exploration :
réactivé ;
- Détection
TypeGuessRow : les dll
msaexp30.dll et msexcl40.dll peuvent être présentent sans qu'Office 2003 soit
installé complètement, dans ce cas, c'est bien le mode OfficeXP
qui fonctionne : il faut donc là aussi augmenter la valeur.
- bCleRegistreExiste -> bCleRegistreLMExiste
(LM pour Local Machine <> CR pour Classe Root) ;
- Requête
insertion : ne pas faire oRq.Close() (ce n'était pas un oubli).
- ODBCExcelTypeGuessRowsParDefaut.reg pour rétablir la valeur
par défaut ;
- Doc sur
Excel 2007 : comment faire de l'ODBC sur des fichier en version 2007 ;
- Correction
exploration des tables : compteur des tables effectivement analysées ;
- Démo
ODBC : ne pas copier dans le résultat dans le presse-papier : proposer
d'afficher directement le résultat ; mise en commentaire l'analyse du
tableau ;
- Passage
en DotNet2, classe partielle pour le designer.
- Correction
chronométrage.
- Affichage
de l'avancement si bcp de rq
écriture : Mod 100 ;
- Autre
table fantôme Excel : [MonClasseur$_].
- Gestion
des tables fantômes d'Excel : [xxx$Impression_des_t].
- VerifierConfigODBCExcel aussi pour connexion directe ;
- Me.m_bLireToutDUnBlocRapide.
- Plus
d'information pour le mode debug : heure et délai de
chaque étape, et l'ajout d'un entête permet un import rapide dans Excel, ceci
avant tout traitement des données (excepté la gestion du séparateur décimal,
des booléens, et le TrimEnd) ;
- Optimisation
en vitesse : m_iNbEnregAlloues : allocation des
lignes par bloc de 100 par défaut (puis réduction à la fin au nombre de ligne
exact) : très efficace ;
- Optimisation
en vitesse : m_bLireToutDUnBloc (méthode ADODB.GetString), test réalisé : beaucoup plus rapide pour
lire un fichier Excel en local, mais pas de gain constaté pour lire dans un PGI
sur le réseau, et on n'a plus l'avancement en temps réel (attention : le format
des dates obtenues peut être différent de la méthode standard) ;
- Gestion
des exceptions au démarrage : Try Catch ajouté dans
la fonction Main() ;
- Fonction
LibererRessources pour alléger la RAM entre chaque
appel à bLireSourceODBC ;
- m_bCopierDonneesPressePapier distingué de bRenvoyerContenu ;
- m_bInterrompreSeulementRqEnCours distingué de bNePasInitAnnulation ;
- m_bAnnulerTout est remplacé par m_bNePasInitAnnulation,
et la propriété m_bAnnuler est maintenant privée : on
peut demander une annulation, et vérifier s'il y a une annulation, mais on n'a
plus à mettre cette variable à faux (automatique, sauf si m_bNePasInitAnnulation) ;
- Utilisation
de propriétés de la classe au lieu du passage de paramètres entrées et sorties,
pour simplifier l'utilisation de la classe ;
- Explorateur
de source de données ;
- Gestion
des commentaires dans le DSN, lors de la vérification de la source de
données ;
- Correction
du bug lorsque la requête ne renvoie aucun enregistrement : le tableau doit
être vide, plutôt qu'un nombre de ligne à 1 avec nothing
pour valeur ;
- DSN DB2 : correction de la ligne PKG (vérifiez le DSN en passant
par l'assistant
ODBC de Windows).
- Génération du DSN pour DB2 (iSeries d'IBM, anciennement AS/400) via le pilote Client Access, et Navision (Microsoft Business Solutions) via le pilote C/ODBC ;
- Requête
en écriture si le pilote ODBC le permet ;
- Amélioration
des fonctions AfficherMsgErreur2 et CopierPressePapier ;
- Numérotation des requêtes SQL : utile s'il y en a plusieurs ;
- Vérification
du nombre de champs attendus : si et seulement si ceux-là sont
définis (pour éviter un bug de dépassement du tableau du nombre de champs
attendus par requête) ;
- Booléen
m_bErreursLecture pour la présence d'au moins une
erreur de lecture de la valeur d'un champ ;
- Si une
annulation est demandée, ne pas poursuivre les autres requêtes : nouvelle
propriété m_bAnnulerTout (fixée à vrai par
défaut) ;
- Distinction
entre ligne vide et nombre de colonnes incorrect : si une requête ne renvoie
aucun enregistrement, mais avec le bon nombre de colonnes (s'il y avait eu des
données), alors ce n'est pas une erreur aussi grave : renvoyer quand même un
tableau vide avec le bon nombre de colonnes ;
- Possibilité
de ne pas vérifier la présence d'une source ODBC de type non fichier via la
nouvelle propriété m_bVerifierFichierSourceDonnees :
si la source ODBC est un service reposant sur une base de données de type
serveur, on ne peut pas localiser la source directement comme un simple fichier ;
- Amélioration
de VerifierConfigODBCExcel ; pour Excel < 2003,
possibilité de fusionner directement le fichier ODBCExcelAugmenterTypeGuessRows.reg
pour augmenter la valeur afin de lire un plus grand nombre de lignes pour
déterminer le type de données capable de stocker les valeurs d'une colonne
Excel (2048 au lieu de 8 par défaut) ;
- bCleRegistreExiste : si la sous-clé n'existe pas, renvoyer
une chaîne vide au lieu de Nothing ;
- Possibilité
de ne pas générer des événements pour afficher le détail des opérations en
cours via la nouvelle propriété m_bAfficherMsg.
http://fr.wikipedia.org/wiki/ODBC
http://en.wikipedia.org/wiki/Odbc
http://en.wikipedia.org/wiki/Database_Source_Name
- XLDB : Une
base de données Excel via ODBC
Code source : XLDB.vbp.html
- XL2Csv :
Convertir un fichier Excel en fichiers Csv (ou en 1 fichier txt)
Code source : XL2Csv.vbproj.html
- Explorateur
SQL Server (comprend un module d’export qui permet d’exporter les résultats les
stocker dans un format ascii, xml, excel, email, impression, ...)
www.csharpfr.com/code.aspx?ID=37230
- Version
VB6 de l'explorateur de base de données Access ou ODBC : cf. DBComp