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

www.vbfrance.com/code.aspx?ID=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

Documentation. 2

Conversion des valeurs en chaînes de caractères via ToString. 2

Notes sur la conversion en nombre réel 2

Syntaxe pour l'écriture des critères sur des dates. 3

Assistant ODBC de Windows. 3

Risque de sécurité. 3

Fichier Excel 2007. 4

Exemples de DSN.. 4

Exemple de DSN pour Access. 4

Exemple de DSN pour Excel 5

Exemple de DSN pour Omnis. 6

Exemple de DSN pour Navision. 6

Exemple de DSN pour DB2. 7

Historique des versions. 7

Version 1.12 du 11/12/2011. 7

Version 1.11 du 13/04/2008. 8

Version 1.10 du 26/01/2008. 8

Version 1.09 du 25/11/2007. 8

Version 1.08 du 22/11/2007. 8

Version 1.07 du 17/11/2007. 8

Version 1.06 du 08/11/2007. 8

Version 1.05 du 12/05/2007. 8

Version 1.04 du 11/03/2007. 8

Version 1.03 du 20/01/2007. 8

Version 1.02 du 11/11/2006. 8

Version 1.01 du 16/04/2006. 9

Version 1.00 du 19/11/2005 : Première version. 9

Liens. 9

Documentation. 9

Voir aussi 9

 

Documentation

 

Conversion des valeurs en chaînes de caractères via ToString

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.

 

Notes sur la conversion en nombre réel

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.

 

Syntaxe pour l'écriture des critères sur des dates

- 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'

 

Assistant ODBC de Windows

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.

 

Risque de sécurité

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 !

 

Fichier Excel 2007

Voir ici pour la lecture des fichiers Excel 2007 via ODBC :

http://blogs.developpeur.org/coq/archive/2007/09/21/classeurs-excel-via-oledb-et-pour-les-versions-2007-xlsb-xlsm-xlsx.aspx

 

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";

www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7554f536-8c28-4598-9b72-ef94e038c891

 

Et en 64 bits :

http://blogs.codes-sources.com/coq/archive/2007/11/25/microsoft-ace-oledb-12-0-en-64-bit.aspx

 

 

Exemples de DSN

 

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

 

Exemple de DSN pour Access

[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

 

Exemple de DSN pour Excel

[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.

 

Exemple de DSN pour Omnis

[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.

 

Exemple de DSN pour Navision

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 de DSN pour DB2

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.

 

 

Historique des versions

 

Version 1.12 du 11/12/2011

- <PlatformTarget>x86</PlatformTarget>, voir ici :

  Comment faire fonctionner ODBC avec Windows 64 bits ?

 

Version 1.11 du 13/04/2008

- 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.

 

Version 1.10 du 26/01/2008

- Vérification du mode Excel : Correction auto de TypeGuessRow par le code.

 

Version 1.09 du 25/11/2007

- 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.

 

Version 1.08 du 22/11/2007

bCleRegistreExiste -> bCleRegistreLMExiste (LM pour Local Machine <> CR pour Classe Root) ;

- Requête insertion : ne pas faire oRq.Close() (ce n'était pas un oubli).

 

Version 1.07 du 17/11/2007

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.

 

Version 1.06 du 08/11/2007

- Correction chronométrage.

 

Version 1.05 du 12/05/2007

- Affichage de l'avancement si bcp de rq écriture : Mod 100 ;

- Autre table fantôme Excel : [MonClasseur$_].

 

Version 1.04 du 11/03/2007

- Gestion des tables fantômes d'Excel : [xxx$Impression_des_t].

 

Version 1.03 du 20/01/2007

VerifierConfigODBCExcel aussi pour connexion directe ;

Me.m_bLireToutDUnBlocRapide.

 

Version 1.02 du 11/11/2006

- 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).

 

Version 1.01 du 16/04/2006

- 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.

 

Version 1.00 du 19/11/2005 : Première version

 

 

Liens

 

Documentation

http://fr.wikipedia.org/wiki/ODBC

http://en.wikipedia.org/wiki/Odbc

http://en.wikipedia.org/wiki/Database_Source_Name

 

Voir aussi

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