ODBC est une norme (Microsoft) offrant un accès transparent à des bases de données (éloignées ou non). Une application WINDOWS compatible ODBC, peut ainsi accéder à une base de données en ne connaissant que son nom logique. La couche ODBC, va activer le driver adéquat (il y a un driver par base) qui lui-même va faire le lien avec la base réelle. Dans le cas de l'AS/400, le driver livré avec Client/Access, va établir un dialogue APPC avec l'AS en s'appuyant sur le routeur. [le JOB AS/400 est QZDAINIT) ou bien un dialogue IP (basé sur les sockets) avec WINDOWS95 et TCP/IP [le JOB AS/400 est QZDSOAINIT) Dernier point (Important) toutes les requêtes transmises au driver sont à la syntaxe SQL, et les requêtes sont exécutées sur le serveur. (ici l'AS) |
Driver ODBC - Client/Access pour DOS étendu ! Application micro ! EXCEL, Visual Basic, ... | ! ODBC.DLL ! (fourni par Microsoft) ATTENTION : | ! livré via PTF ---> EHNODBC.DLL ! driver ODBC C/A uniquement | ! EHNRQW.DLL ! Remote SQL APIs | ! EHNAPPC.DLL ! APPC APIs | ! STARTRTR.EXE ! routeur PCS-Client/Access | ! ====================================================== | ! AS/400 (RDBMS) ! Fonctions serveur de l'AS ! [Remote Data Base ! Management System] |
Driver ODBC - Client/Access pour WINDOWS 3.1 ! Application micro ! EXCEL, Visual Basic, ... | ! ODBC.DLL ! (fourni par Microsoft) | ! livré avec CAWIN-> EHNODBC3.DLL ! driver ODBC C/A p. WIN | ! EHNAPPC.DLL ! APPC APIs | ! | ! (utilise le VxD de CAWIN) | ! ====================================================== | ! serveur hôte --> AS/400 (RDBMS) ! Fonctions serveur de l'AS ! [Remote Data Base ! Management System] |
Driver ODBC - Client/Access pour WINDOWS 95/NT ! Application micro ! EXCEL, Visual Basic, ... | ! ODBC32.DLL ! (fourni par Microsoft) | ! livré avec CAWIN-> CWBODBC.DLL ! driver ODBC C/A p. WIN | ! routines APPC ! (NETSOFT) ou TCP/IP ! (IBM) | ! | ! ====================================================== | ! serveur hôte --> AS/400 (RDBMS) ! Fonctions serveur de l'AS ! [Remote Data Base ! Management System] |
l'AS/400 se comporte vraiment comme un serveur. 1/ il déclenche des jobs qui sont en attente de vos requêtes (afin de répondre au plus vite) -> voir le cours AS/400 fonctions serveur hôte. 2/ il peut être utilisé comme une passerelle avec d'autres systèmes dans le cadre de DRDA. D'ailleurs le nom de base de donnée indiqué est votre nom DRDA local. il vous suffit de passer (via ODBC) un ordre SQL CONNECT, pour que vos requêtes SQL soient exécutées sur le site DRDA indiqué. Il va créer dans QIWS un SQLPACKAGE (QZDAINIT) qui contiendra les paramètres nationaux (marque décimale, convention d'appellation, ...) |
ET, il utilisera des fichiers catalogues particuliers afin de constituer la liste des tables, des vues et la liste des colonnes. il s'agit des fichiers (LF) QAZD.... situés dans QIWS qui s'appuient sur les nouveaux fichiers QADBXREF (etc ...) de QSYS Autres particularités du driver ODBC : il ne connaît pas la notion de membre [SQL ne connaît pas] vous pouvez quand même outrepasser de la manière suivante: + SQL/400 admet maintenant la notion de procédure cataloguée (voir le cours SQL-V3R10) ==> vous pouvez appeler un pgm dans une instruction SQL Y COMPRIS avec ODBC ! sous la forme CALL BIB.PGM (param1,param2, ....) |
si vous n'indiquez pas "BIB." l'AS cherche dans *LIBL, partie utilisateur Exemple CALL QSYS.QCMDEXC ('OVRDBF TOTO MBR(xxx) OVRSCOPE(*JOB)', 0000000035,00000) ça marche !! Quelques explications : le premier paramètre est entre quotes (il s'agit d'une constante alpha) la substitution doit être valable pour l'ensemble du job (le pgm qui passe la commande n'étant plus actif après) la longueur doit être indiquée avec 10 entiers, 5 décimales (15dt5) la marque décimale doit être celle indiquée dans les paramètres. vous pouvez donc appeler n'importe quel programme, mais en plus passer n'importe quelle commande !!! |
ET ENFIN : les paramètres des fichiers .INI ODBCINST.INI = drivers [dBase Files (*.dbf)] installés. Driver=C:\WINDOWS\SYSTEM\SIMBA.DLL Setup=C:\WINDOWS\SYSTEM\SIMADMIN.DLL ......................... : Dans WINDOWS 95 : [Paradox Files (*.db )] : : Driver=C:\WINDOWS\SYSTEM\SIMBA.DLL : il s'agit du registre : Setup=C:\WINDOWS\SYSTEM\SIMADMIN.DLL : : : HKEY_LOCAL_MACHINE/ : [SQL Server] : SOFTWARE/ODBC/ : Driver=C:\WINDOWS\SYSTEM\SQLSRVR.DLL : ODBCINST.INI : Setup=C:\WINDOWS\SYSTEM\SQLSRVR.DLL : : : : [ShowCase ODBC] : : driver=C:\WINDOWS\SYSTEM\scodbc.dll :.......................: setup=C:\WINDOWS\SYSTEM\scodbc.dll [Client Access/400 ODBC Driver] Driver=d:\cawin\ehnodbc3.dll <-- nom du driver Setup=d:\cawin\ehnstp3.dll <-- nom du pgm de configuration |
les paramètres des fichiers .INI ODBC.INI = définition des sources de données [ODBC Data Sources] et paramétrage Bases de données MS Access=Access Data (*.mdb) Fichiers FoxPro=FoxPro Files (*.dbf) Fichiers dBASE=dBase Files (*.dbf) ......................... Fichiers Paradox=Paradox Files (*.db ) : Dans WINDOWS 95 : Les Comptoirs=dBase Files (*.dbf) : : prof=Access Data (*.mdb) : il s'agit du registre : AF400=Client Access/400 ODBC Driver <-- : : : HKEY_CURRENT_USER/ : [Bases de données MS Access] : SOFTWARE/ODBC/ : Driver=C:\WINDOWS\SYSTEM\SIMBA.DLL : ODBC.INI : FileType=RedISAM : : SingleUser=False : : UseSystemDB=False : : :.......................: [Fichiers FoxPro] Driver=C:\WINDOWS\SYSTEM\SIMBA.DLL |
ODBC.INI (suite ...) (les commentaires anglais sont ceux écrits par le pgm de configuration) [AF400] Driver=d:\cawin\ehnodbc3.dll [cwbodbc.dll pour Windows 95] Description=Pilote ODBC de Client Access/400 System=S4409790 UserID= ; ; Si vous indiquez ici un profil vous devrez vous signer à chaque ; connexion, sinon le driver utilise le profil du routeur. CommitMode=0 ; *NONE (Validation immédiate) DefaultLibraries=AF400,AF4SRC ; ; liste des bibliothèques utilisables avec en plus *USRLIBL admis ; Naming=0 ; *SQL (Convention d'appellation SQL.) ; ; liste des paramètres nationaux DateFormat=5 ; *ISO (format de date aaaa-mm-jj) DateSeparator=0 ; Séparateur de date / (barre oblique) TimeFormat=0 ; *HMS (format d'heure hh:mm:ss) TimeSeparator=0 ; Séparateur d'heure : (deux-points) Decimal=1 ; Séparateur decimal , (virgule) |
ForceTranslation=0 ; *0=No translate for CCSID 65535, 1=Translate CCSID 65535 LibraryView=0 ; *0=Library list, 1=All libraries on the system ODBCRemarks=0 ; *0=OS/400 object description (texte de l'objet) ; 1=SQL/400 object comment (commentaire SQL) AlwaysScrollable=0 ; *0=No scrollable cursor if row set is 1 ; 1=Always scrollable LazyClose=1 ; 0=Immediate close, ; 1=LazyClose enabled ; ->les fichiers sont fermés lors de la prochaine instruction ; (ce qui évite une E/S entre PC et AS) ; MAIS: Attention aux enregistrements qui restent verrouillés RecordBlocking=2 ; 0=Disabled (lignes extraites une par une) ; 1=Block if FOR FETCH ONLY specified, ; 2=Block except for FOR UPDATE OF specified BlocksizeKB=32 ; taille du bloc /(1 à 512 Ko (Défaut = 32) ; ; attention : aux applications qui n'affichent les premiers ; enregistrements que quand le bloc est entier (ACCESS) |
; ; pour finir: ce qui va probablement impacter le plus les performances ; ; ExtendedDynamic=1 : utilisation de SQLPACKAGEs sur l'AS/400. ; ExtendedDynamic=1 ; 0=Disabled, *1=Enabled PackageSQLIBM=QGPL/SQLIBM(FQA),2,0,1 PackageMSQUERY=QGPL/MSQUERY(FBA),2,0,1 PackageMSACCESS=QGPL/MSACCES(FBA),2,0,1 PackageCRW=QGPL/CRW(FBA),2,0,1 Rappel : lors de la compilation d'un pgm SQLxxx (SQLRPG, ....) , le pré-compilateur crée pour chaque reqête SQL un plan d'accès (méthode d'accès choisie, index(s), estimation du coût CPU, etc...) Ces plans d'accès sont stockés dans un SQLPACKAGE. si vous travaillez en local ce SQLPACKAGE est lui-même intégré au programme. (visualisable avec PRTSQLINF, nouvelle commande V3R10) |
MAIS : si vous travaillez avec une base éloignée, - si la ligne est active au moment de la compilation, il y a création d'un objet *SQLPKG sur l'AS distant (celui où se trouve la base) - sinon, vous pourrez, quand la ligne sera active, passer la commande : CRTSQLPKG en fournissant les coordonnées du pgm local. Ce SQL PACKAGE améliore nettement les performances sur le site distant lors de l'exécution de la requête. C'est cette technique qui a été utilisée avec ODBC. Syntaxe : PackageAPPLICATION=bib/racine(xxx),u,p,e PackageAPPLICATION est une entrée par nom d'application micro PackageMSACCESS pour Microsoft-ACCESS PackageSQLIBM pour l'extracteur de Client/Access PackageCRW pour Crystal Report p. WIndows .... |
bib/racine(xxx) fournit le nom de l'objet *SQLPKG sur l'AS/400 racine est en général les sept premiers caractères de l'application xxx est un suffixe (non modifiable) qui représente une combinaison des paramètres nationaux. FBA = français,convention SQL,marque décimale = ',' FQA = idem , idem ,marque décimale = '.' (difficile de connaître l'algorithme extact) "bib/" est la bibliothèque où se trouve cet objet ainsi: PackageSQLIBM=QGPL/SQLIBM(FBA), indique l'utilisation d'un objet *SQLPKG SQLIBMFBA situé dans QGPL. ATTENTION: à chaque nouvelle requête un nouveau plan d'accès sera placé dans le SQL PACKAGE. Peut-être faut-il envisager de les placer dans une bibliothèque dédiée à l'utilisateur. |
Dans le cas de SQLIBM : probablement, les requêtes d'un utilisateur étant complètement libres, il y a peu de chances qu'un utilisateur exécute des requêtes identiques à celles de ses collègues par contre lui-même peut réutiliser fréquemment les mêmes (à voir ???) Dans le cas d'une application client/serveur, chaque utilisateur devrait passer les mêmes requêtes, celles-ci étant contrôlées par l'application. Comme vous le voyez, le réglage de ces paramètres dépend de chaque entreprise, mais aussi de l'application, voire de l'utilisateur. 1/ Utilisation fréquente ou non du driver ODBC ? 2/ Requêtes portant généralement sur les mêmes fichiers ??? En tout état de cause, il semble TRES DECONSEILLE de laisser comme bibliothèque par défaut QGPL, qui devient une bibliothèque fourre-tout de plus en plus considérée comme une bibliothèque IBM. |
paramètres supplémentaires (PackageAPPLICATION=racine(xxx),u,p,e) ----- u : 0 = ne pas utiliser de SQL PACKAGE pour CETTE application (la probabilité de réutilisation est faible) 1 = utiliser un SQL PACKAGE (s'il en exite un), mais en lecture seule (mise à jour implicite du SQL PACKAGE impossible) 2 = (val par défaut) lecture/création/modification du SQL PACKAGE p : que faire quand le PACKAGE est plein (en effet un SQL PACKAGE ne peut pas contenir un nombre infini d'instructions) 0 : (val par défaut) l'utilisation du SQL PACKAGE devient lecture seule ==> voir alors le troisième paramètre [e] 1 : mise à blanc du SQL PACKAGE e : comment signaler l'erreur quand le SQL PACKAGE est plein 0 : ne pas signaler l'erreur 1 : envoyer une erreur de type WARNING (attention certaines application s'arrêtent sur un message WARNING) 2 : signaler une erreur de type arrêt programme. |
Ces paramètres d'optimisation ne sont pas tous accessibles via le programme de configuration du driver. Sous WINDOWS 3.1 : Vous devez donc les modifier directement dans le fichier ODBC.INI à l'aide d'un éditeur (NOTEPAD.EXE) Ou bien par pgm (VB par exemple) en utilisant les APIs WINDOWS : GetPrivateProfilString et GetPrivateProfilInt pour retrouver la valeur d'un paramètre (char ou entier) dans une section d'un fichier INI. WritePrivateProfilString et WritePrivateProfilInt pour donner une valeur à un paramètre (char ou entier) dans une section. ou en Visual Basic, utiliser l'instruction "RegisterDataBase" ATTENTION : Un mauvais paramétrage peut empêcher ODBC de fonctionner. |
Sous WINDOWS 95/NT : Utiliser l'éditeur de registre (REGEDIT) il est possible d'exporter et d'importer une partie du registre ou la méthode (en VB4) RegisterDataBase de l'objet DBENGINE(0) les APIs WritePrivatePofileString et GetPrivateProfilString ne peuvent plus être utilisées, puisqu'elles travaillent toujours avec des fichiers. VB4 propose une instruction SaveSetting et une fonction GetSetting mais qui mémorisent des informations sous la clé : "HKEY_USER/[votre licence].../Software/VB and VBA Programm Settings" |
Pour accéder aux Bases ODBC depuis LOTUS 123 (Windows 3.1) vous devez rajouter les lignes suivantes DN="AS/400" DL="DLODBC" DD="ODBC pour AS/400" DC="driver=c:\cawin\ehnodbc3.dll"; dans le fichier c:\Windows\Lotusapp\Datalens\lotus.BCF en cours d'utilisation, choisissez "Outils/Base de données/Nouvelle interrogation" et appuyez sur le bouton externe Depuis EXCEL et WORD vous utiliserez le Produit MS-QUERY |
Pour accéder aux Bases ODBC, VISUAL BASIC et VBA, (Visual Basic for Application qui remplace les macros EXCEL4 pour EXCEL5), possèdent des codes spécifiques : VBA : SQLOpen établit une connexion avec une base ODBC SQLBind détermine l'endroit où placer le résultat d'une requête SQLClose rompt une connexion SQLError renvoie le détail d'une erreur SQLExecQuery exécute une requête passée en argument SQLGetShema renvoie des informations sur la base. SQLRequest établit une connexion ET exécute une requête SQLRetrieve extrait les résultats d'une requête SQLRetrieveToFile extrait les résultats et les place dans un fichier Quand à Visual Basic, il s'agit d'un véritable langage de programmation En voici les principales caractéristiques (concernant l'accès aux Bases) |
Dim Db As Database '(définition d'une base) Dim Sn As Snapshot '(définition d'un curseur SQL) Dim requete '(variable contenant la requête) Set Db = OpenDatabase("nom_de_la_base", False, False, "ODBC;") ' (mode exclusif) (lecture seule) 'si nom_de_la_base n'est pas renseigné, ODBC vous affiche une liste requete = "SELECT CLIENTS.DEPCLI, SUM(ENTFAC.MNTFAC - ENTFAC.MNTPAI)" requete = requete & "FROM CLIENTS, ENTFAC " requete = requete & "WHERE CLIENTS.CODCLI = ENTFAC.CODCLI " requete = requete & "GROUP BY DEPCLI " requete = requete & "HAVING SUM(ENTFAC.MNTFAC - ENTFAC.MNTPAI) > 0" Set Sn = Db.CreateSnapshot(requete) Sn.MoveFirst While Sn.EOF = False 'traitement de Sn(0)= colonne1, Sn(1) = colonne 2 , etc... Sn.MoveNext Wend |
En VB4 vous pouvez utiliser l'objet WORKSPACE qui représente un espace de travail pour gérer les transactions. Dim WS As WORKSPACE '(définition d'un espace de travail) Dim Db As Database '(définition d'une base) ... .... Set WS = WORKSPACE(0) 'espace de travail par défaut Set Db = WS.OpenDatabase("nom_de_la_base", False, False, "ODBC;") ' (mode exclusif) (lecture seule) .... [idem ensuite] et vous pouvez gérer les transactions (commit/rollback): ws.Bengintrans WS.CommitTrans = COMMIT et WS.Rollback = ROLLBACK |
EN REGLE GENERALE, Si vous recevez une erreur : [Microsoft][ODBC.DLL]<-- texte du message--> : Il s'agit d'une erreur renvoy{e par la couche ODBC microsoft locale. [IBM][Client Access]<--le texte du message--> : Il s'agit d'une erreur renvoy{e par Client Access (erreur micro). [IBM][Client Access][DB2/400]SQLxxxx <--le texte--> : Il s'agit d'une erreur renvoyée par l'AS/400. Vous pouvez alors regarder l'historique du job AS/400 qui répond à votre micro.Pour cela, ouvrez une session et tapez : WRKCFGSTS *DEVD CFGD(nom-du-micro) Vous verrez l'état de l'unité (normalement active) et TOUS les jobs associés (rappel, pour ODBC, ils sont initialisés sous QUSER). |