Afficher les contraintes d'une base

**ruiz.nicolas** · 19/11/2007, 11h07

Bonjour à tous,

Je suis en reverse engineering sur une base DB2400 : 2800 et quelques tables...

Je voudrais récupérer le schema de cette base. J'ai donc requeté en ODBC quelques tables de QSYS2 : j'ai bien récupéré les infos sur QSYS2.SYSTABLES et QSYS2.SYSCOLUMNS (infos concordantes celles de DTM SQL Editor) mais rien n'est dispo sur QSYS2.SYSCST ou QSYS2.SYSCSTCOL concernant mes clés primaires (pourtant listées par DTM).

Où dois-je checker sinon dans mon QSYS2 ?!

Merci d'avance pour vos lumières.

Nico.

**Hédhili Jaïdane** · 19/11/2007, 19h24

Bonjour.

Tu peux obtenir des infos sur les contraintes par :
- DSPFD *all/*all type(*cst)
- WRKPFCST ...
- DSPDBR ...

Iseries Access sur V5R4 le fait aussi il me semble

**ruiz.nicolas** · 20/11/2007, 07h43

Bonjour Hédhili,
Et merci pour votre retour.

J'ai en effet déjà pu afficher mes contraintes par la commande :
DSPFD FILE(MA-BIBLIO/*ALL) TYPE(*CST)

Malheureusement, je dois trouver l'équivalent en requête SQL.
En effet, j'attaque mon AS/400 par ODBC depuis un serveur Linux.
Le but est de répliquer dynamiquement et quotidiennement la base DB2/400 sur une base MySQL : le schéma de la base DB2 pouvant évoluer dans le temps, je dois récupérer son schéma à chaque synchronisation.

J'ai correctement récupéré les infos des tables et des colonnes mais mes contraintes ne semblent pas stockées dans la bibliothèque QSYS2.
Pour info, je ne peux pas faire de batch automatisés sur mon AS/400 : je ne peux qu'exécuter des commandes ponctuelles. C'est ainsi que j'ai récupéré le nombre d'enregistrement par table :
DSPFD FILE(MA-BIBLIO/*ALL) TYPE(*MBRLIST) OUTPUT(*OUTFILE) OUTFILE(QTEMP/OUTPUTNR)
J'ai ensuite requêté QTEMP/OUTPUTNR depuis mon serveur Linux mais cela ne sera pas possible de manière automatisée.

Cordialement,
Nicolas RUIZ.

**ruiz.nicolas** · 20/11/2007, 08h53

Je reviens sur ce que j'ai dis. Les commandes exécuté sur le shell AS400 ne m'affichent pas mes contraintes ...

WRKPFCST FILE(MA-BIBLIO/*ALL TYPE(*ALL)
-> (Aucune contrainte à afficher)

DSPFD FILE(MA-BIBLIO/*ALL) TYPE(*CST)
-> (Aucune contrainte ajoutée au fichier) pour tous mes fichiers

DSPDBR FILE(MA-BIBLIO/*ALL)
-> Quelques dépendances de données trouvées, sans contraintes (non systématiques, disons 20% de la base)

Pourtant, mon petit outil DTM SQL Editor, lui aussi relié par ODBC sur la même base (mais depuis mon système Windows), me donne, pour 80% des tables, une clé primaire (pas de clés étrangères ou autre) :
-> ALTER TABLE MA-BIBLIO.UNE-TABLE ADD CONSTRAINT SpecialColumn PRIMARY KEY (CHAMP1, CHAMP2)

Les clés sont toujours nommées "SpecialColumn", quel que soit la table sur laquelle elle est appliquée. Elles peuvent par contre inclure une, deux ou plusieurs tables (pas forcement dans l'ordre d'affichage de celles-ci).

Je continue de prospecter. Si j'avais vous aviez quelques éclaircissements à me donner ... Je manque de recul sur ce système : je le découvre depuis 2semaines, partant de rien ...

**Hédhili Jaïdane** · 20/11/2007, 09h59

Bonjour Nicola,
Bonjour tout le monde.

D'abord je suis nul en SQL (c'est provisoire) et désolé j'étais absorbé par une installation et le démarrage d'un 515 V5R4 avec une migratipon d'applics S/36 dessus.

Pour ton histoire d'automatisation, tu peux toujours écrire un prog. CL et y mettre toutes les commandes que tu passes puis tu le compiles. Tu peux y mettre un DLYJOB pour qu'il continue l'exécution à une heutre donnée ou le mettre dans une entrée des travaux planifiés (WRKJOBSCDE)

Pour les contraintes, regarde si tu ne trouves pas quelque chose dans ces fichiers :
- Referential constraint file information (QSYS/QADBFCST)
- Referential constraint field information (QSYS/QADBCCST)

Et puis, si je me permets, n'hésite pas à consulter les centres d'info d'IBM en fonction de ta version

http://publib.boulder.ibm.com/infoce...v5r4/index.jsp

A+

**ruiz.nicolas** · 20/11/2007, 11h29

C'est incroyable, aucune information non plus, pour ma bibliothèque, en réponse à ma requête de selection sur QSYS/QADBFCST ou QSYS/QADBCCST...

A croire que DTM SQL Editor me génère les clés à lui tout seul !

Je suis déjà depuis plusieurs jours sur les docs réferences d'IBM, je vais continuer ma lecture.

@+

**Hédhili Jaïdane** · 20/11/2007, 11h53

Il y a quand même quelques choses concernant d'autres biblios et d'autres fichiers dans QSYS/QADBFCST ou QSYS/QADBCCST ?

**ruiz.nicolas** · 20/11/2007, 12h33

**Green Hornet** · 20/11/2007, 23h21

Envoyé par ruiz.nicolas

A croire que DTM SQL Editor me génère les clés à lui tout seul !

il est tout à fait possible qu'il détermine lui même des potentielles clés, il n'y a pas forcément de contraintes au niveau BDD, elles peuvent avoir été gérées par programmation

qu'on me corrige si je dis des âneries à quelques minutes du dodo bien mérité

**ruiz.nicolas** · 21/11/2007, 06h47

Merci pour ta réponse.

A ce moment là, si jamais DTM SQL Editor génère mes clés primaires par décision interne, quels mécanismes pourrait-il avoir employé pour sélectionner les champs à inclure ?

Mes connaissances en SQL sont limitées sur ce point. Est-il possible de requêter une table pour obtenir un n-tuple unique ?! Cela me parait improbable.

Prenons un exemple concret avec ma bibliothèque : la table ACC002W1.
Je vous donne le code SQL rendu par DTM SQL Editor sur sélection de cette table, sachant que j'obtient les mêmes données en requêtant QSYS2.SYSTABLES et SYSCOLUMNS :

create table MMBASLIB.ACC002W1(
W1DAT NUMERIC(6) NOT NULL,
W1BCH NUMERIC(8) NOT NULL,
W1STR NUMERIC(3) NOT NULL,
W1SUPP NUMERIC(6) NOT NULL,
W1DPT NUMERIC(3) NOT NULL,
W1TOFA NUMERIC(15,2) NOT NULL,
W1TOTR NUMERIC(15,2) NOT NULL,
W1DIF NUMERIC(7,2) NOT NULL
)

Par contre, les données suivantes restent pour l'instant cachées à mes requêtes SQL ou systèmes (DSPFD, etc...) :

create index ACC002W1
on MMBASLIB.ACC002W1 (W1STR asc, W1SUPP asc, W1DPT asc, W1BCH asc)

ALTER TABLE MMBASLIB.ACC002W1
ADD CONSTRAINT SpecialColumn
PRIMARY KEY (W1STR, W1SUPP, W1DPT, W1BCH)

On remarque que la liste des champs constituant la clé primaire n'est pas dans l'ordre d'affichage des champs de la table (celui-ci étant noté en dur dans la table QSYS2.SYSCOLUMNS).
On remarque aussi qu'il ne sélectionne pas les constituants de la clé par le type des colonnes, il aurait inclu W1DAT sinon...

Enfin bref, je nage en plein désarroi ... Sur ce, je retourne bouquiner les Red Books d'IBM.
Je finirais peut-être par avoir le niveau pour une certif système AS400 lvl01

(à défaut d'aboutir tout de suite sur cet aspect de mon projet

)

**Green Hornet** · 21/11/2007, 23h15

alors pour ce qui est du reverse engineering, des outils gratuits tels que DBDesigner 4 sont capables de déduire d'une base MySQL les relations existantes entre les différentes tables, donc je suppose, je n'affirme pas, nuance

, que le logiciel que tu utilises est capable de faire des merveilles... mais bon un jour après ma réponse, je me rends compte que j'ai peut être été un peu vite sur la lecture de ton soucis

j'avais bien fait de préciser "qu'on me corrige si je dis des âneries à quelques minutes du dodo bien mérité"

enfin bref, pour info, en DB2400, sur un fichier (une table en langage micro), tu peux créer des index bien entendu mais tu as surtout la possibilité de créer ce que l'on nomme des fichiers logiques, des index, qui n'ont pas été créés par sql mais à partir de fichier source puis compiler, ces logiques pointant sur des logiques (de 1 à plusieurs si jointure) sont peut être à la base de la détermination des cléfs par ton logiciel...

je ne suis pas sur de moi, mais un index au sens sql du terme, ne permet pas de sélection ou d'omission tandis que les logiques permettent de préciser des clefs d'accès et/ou d'unicités tout en y précisant des filtres sur les différents champs composant les clefs...

**ruiz.nicolas** · 22/11/2007, 05h46

Bonjour messieurs,

J'ai requêté par STRSQL la table QSYS.QADBKFLD et j'ai retrouvé mes clés dessus. La table est architecturée avec chaque enregistrement comme un des champs de l'index d'une table, son ordre dans la liste et la biblio/table à partir de laquelle le champ est extrait. J'ai créé une petite routine qui me recréé une requête de création de clé primaire en SQL à partir de ces informations.

Il est vrai après qu'il s'agit d'index et non de clés. Si ma base contient deux ou plus index par table, ma logique tombe. Si ma base contient des clés étrangères, ma logique tombe aussi, à priori. Mais il faut que j'aille très vite et il me semble en étudiant en diagonale ma base qu'elle ne contenait que aucun ou un index : aucune ou une clé primaire par table, pas de clés étangères.

A suivre donc. Merci beaucoup pour votre aide les gars...