Récupérer nom BDD et pas nom alias en SQL

[prisme.erp]

Bonjour,

Sur l'utilisation de certains produits comme Cognos Impromptu ou Pentaho :
Est-il possible de récupérer sur un select * en SQL les noms des "rubriques" et non les noms des alias ?
En d'autres termes, sur un SELECT * FROM ARTICLES, je souhaite retourner ceci :

Code :

1
2
3
4
5
6
7
CODART  | LIBART             |
123456   | Article 123456   |

Actuellement, la requête me retourne ceci :
MMRB000RF | FDRF000RF    |
123456   | Article 123456   |

La seule possibilité que j'ai trouvé est de faire :
SELECT CODART, LIBART FROM ARTICLES

Malheureusement, quand un fichier contient plus de x champs, ça devient très vite contraignant.

Faut-il voir du côté SQL, du driver IBM AS400 ?

Merci de votre aide.

[frfancha]

Envoyé par prisme.erp

Bonjour,
Sur l'utilisation de certains produits comme Cognos Impromptu ou Pentaho :
Est-il possible de récupérer sur un select * en SQL les noms des "rubriques" et non les noms des alias ?
En d'autres termes, sur un SELECT * FROM ARTICLES, je souhaite retourner ceci :

Code :

La seule possibilité que j'ai trouvé est de faire :
SELECT CODART, LIBART FROM ARTICLES

Que veux-tu dire par "nom de rubriques" et "alias" en terme de create table?

[prisme.erp]

Envoyé par frfancha

Que veux-tu dire par "nom de rubriques" et "alias" en terme de create table?

J'utilise AGL-X comme référentiel de données.
J'ai donc un fichier ARTICLES.

Quand je fais un DSPFFD sur ARTICLES, j'ai :
Nom alias . . . . . . . . . . . . . . . . :
MMRB000RF
CODART CHAR 10 0 13 15 E/S Code Article

Nom alias . . . . . . . . . . . . . . . . :
FDRF000RF
LIBART CHAR 20 0 13 15 E/S Libellé Article

En SQL avec des outils comme Impromptu ou Pentaho, le select * me renvoie l'alias (MMRB000RF,FDRF000RF) généré automatiquement par l'AGL.
Je souhaite récupérer CODART, LIBART.

Voilà, j'espère que mes indications supplémentaires suffiront.

[frfancha]

Envoyé par prisme.erp

Quand je fais un DSPFFD sur ARTICLES, j'ai :
Nom alias . . . . . . . . . . . . . . . .

Quand j'ai accès au DSPFFD sur nos tables je regarde et si je trouve quelque chose qui peut t'aider je le mettrai ici.

[prisme.erp]

Envoyé par frfancha

Quand j'ai accès au DSPFFD sur nos tables je regarde et si je trouve quelque chose qui peut t'aider je le mettrai ici.

Merci l'ami !

[K2R400]

Chaque colonne d'une table est défini avec un nom court (10 caractères) et un nom long (128).
SQL favorise le nom long dans les requêtes, c'est logique.
NOCLI est moins parlant que NUMERO_CLIENT

Tu ne peux pas retourner le nom court dans un SELECT *, seul le nom long est retourné.
Ainsi

SELECT * FROM FICCLI renvoie NUMERO_CLIENT
SELECT NOCLI FROM FICCLI renvoie NOCLI
SELECT NOCLI NUMCLIENT FROM FICCLI renvoie NUMCLIENT

Maintenant rien ne t'empêche de définir une vue sur ta table avec les noms de colonne que tu veux.

[frfancha]

Envoyé par K2R400

Chaque colonne d'une table est défini avec un nom court (10 caractères) et un nom long (128).
SQL favorise le nom long dans les requêtes, c'est logique.
NOCLI est moins parlant que NUMERO_CLIENT
Tu ne peux pas retourner le nom court dans un SELECT *, seul le nom long est retourné.

Oui sauf qu'ici il ne parle pas de cela (d'ailleurs les 2 noms de la colonne CODART et MMRB000RF ont moins de 10 caractères).

prisme.erp, peux-tu envoyer le résultat de
select * from qsys2.syscolumns where table_name = 'ARTICLES' and table_schema = 'le nom de la librairie'
pour les colonnes CODART et LIBART?

Comment es-tu arrivé à mettre ces aliases?

[m4k-Hurrican]

Pourtant, il est remarquable que l'outil de transfert d'iSeries Access propose les noms courts par défaut, et qu'il faille cocher la case spécifique pour récupérer les alias.
Dans iSeries Navigator ou via VB6 si je génère une requête "Select * from..." j'obtiens aussi les noms courts.
Peut être y a t'il une option spécifique dans les requêtes SQL sur DB2/400 ?

[K2R400]

Envoyé par m4k-Hurrican

Pourtant, il est remarquable que l'outil de transfert d'iSeries Access propose les noms courts par défaut, et qu'il faille cocher la case spécifique pour récupérer les alias.
Dans iSeries Navigator ou via VB6 si je génère une requête "Select * from..." j'obtiens aussi les noms courts.
Peut être y a t'il une option spécifique dans les requêtes SQL sur DB2/400 ?

Hurrican,

Je viens d'essayer dans iSeries Navigator, Execution de scripts SQL, seuls les noms longs ressortent.
Peux-tu essayer avec cette table ?

Code :

1
2
3
CREATE TABLE QUELNOM ( 
CECI_EST_LE_LIBELLE_DE_MA_PREMIERE_ZONE_QUI_SE_NOMME_ZONE1 FOR COLUMN ZONE1      INTEGER NOT NULL, 
	CECI_EST_MA_ZONE2 FOR COLUMN ZONE2      INTEGER NOT NULL);

[Mercure]

Envoyé par prisme.erp

Est-il possible de récupérer sur un select * en SQL les noms des "rubriques" et non les noms des alias ?

N'y a t'il pas moyen de paramétrer Impromptu ou Pentaho pour obtenir cela ?

Je suppose que tu as déjà fait des recherches dans ce sens, mais je pose quand même cette question à toutes fins utiles, au cas où.

[m4k-Hurrican]

Envoyé par K2R400

Hurrican,

Je viens d'essayer dans iSeries Navigator, Execution de scripts SQL, seuls les noms longs ressortent.
Peux-tu essayer avec cette table ?...

OK, le mystère s'épaissit sur l'utilisation qu'IBM fait des zones en interne.
Il ressort de ce test ceci :
- Si le fichier a été créé par SQL (cas de l'exemple fourni par K2R400), les "alias" de champ sont utilisés en priorité.
- Si le fichier a été créé à partir de DDS (cas de mes tests originaux), les noms courts sont utilisés en priorité.

Pourtant lorsqu'on sort la description des fichier, rien ne semble différencier les zones...

[K2R400]

Bravo Hurrican, information très utile, je n'y avais pas pensé.

Il faut dire, il y a des lustres, plus de 10 ans, que je ne créés plus des tables avec des DDS, c'est déprécié, obsolète, lent et dangereux.
C'est donc normal que son outil génère des DDL.

[frfancha]

Envoyé par m4k-Hurrican

Pourtant lorsqu'on sort la description des fichier, rien ne semble différencier les zones...

Table_type = 'P' (DDS) ou 'T' (SQL) dans systables?

[frfancha]

Envoyé par frfancha

les 2 noms de la colonne CODART et MMRB000RF ont moins de 10 caractères

Ok, au temps pour moi.
Il est impossible de donner un system_name différent du name à une table dont le name fait moins que 10 caractères.
Donner le nom system "lulu" à la table "toto" change aussi le "long" nom de la table qui devient "lulu" = le system name.
Je croyais que cette impossibilité s'appliquat aux colonnes, mais pas du tout:
CREATE TABLE QUELNOM (
toto FOR COLUMN lulu INTEGER NOT NULL);
fonctionne avec la colonne toto ayant le system name lulu.
On voit avec quel environnement on est habitué à travailler dans la manière de parler:
moi j'appelle cela la colonne toto (avec system name lulu), prisme appelle cela la colonne lulu (avec l'alias toto).

[K2R400]

En fait si on veut changer les titres des colonnes il suffit de faire un LABEL ON

Code :

LABEL ON COLUMN MATBALE (MAZONE IS 'MON TITRE')

ce qui revient à modifier le COLHDG.

Pour modifier le texte :

Code :

LABEL ON COLUMN MATBALE (MAZONE TEXT IS 'MON TITRE')

Et en effet, par défaut quand on créé une table avec des DDL, le COLHDG prit par défaut est celui du nom de la colonne (nom long)

[m4k-Hurrican]

Envoyé par K2R400

Il faut dire, il y a des lustres, plus de 10 ans, que je ne créés plus des tables avec des DDS, c'est déprécié, obsolète, lent et dangereux.
C'est donc normal que son outil génère des DDL.

Déprécié et obsolète, soit. Mais lent et dangereux je ne suis pas de cet avis. Les fichiers générés via DDS ne sont ni plus lents, ni plus dangereux que les fichiers générés via SQL. Mieux, les DDS fournissent toujours des possibilités que DDL ne fourni pas (les Select/Omit par exemple). Et historiquement j'ai encore de nombreux fichiers qui n'ont aucun besoin d'être réécrits (certains modules ont 10 ans et marchent très bien), et qui sont donc toujours basés sur des DDS.

[K2R400]

Envoyé par m4k-Hurrican

Déprécié et obsolète, soit.

Si tu es déjà OK sur le point, ça m'évitera d'expliquer en détail pourquoi c'est déprécié et pourquoi les DDS sont totalement obsolètes, donc on passe à la suite.

Envoyé par m4k-Hurrican

Mais lent et dangereux je ne suis pas de cet avis. Les fichiers générés via DDS ne sont ni plus lents, ni plus dangereux que les fichiers générés via SQL.

Et pourtant si !!!!

Alors pourquoi dangereux ?
Tout simplement parce qu'un fichier créé avec des DDS est une entité différente d'une table, malgré qu'ils soient tous les deux représentés sous la forme d'un *FILE PF-DTA.
On peut mettre ce que l'on veut dans un fichier DDS. Fais un CPYF *NOCHK de ton fichier article dans ton fichier client, il accepte en mettant dans tes zones décimales de l'alpha. Tu peux même faire le test à l'ancienne avec un EXCPT d'une zone alpha dans une zone packée, aucun problème il accepte !!!!
Un fichier créé avec des DDS ne contrôle aucune cohérence à l'écriture, il accepte tout, en résumé il n'assure nullement la cohérence et l'intégrité des données, d'où de nombreux soucis de données vérolées sur les zones numériques, les dates, les timestamp etc...
Avec une table (et non un fichier), donc créé avec une DDL, c'est impossible de mettre de l'alpha dans du numérique. L'intégrité est vérifiée au moment de l'écriture, il refusera donc toute incohérence. En resumé, si on veut des données fiables, il faut une table et non un fichier.

Alors pourquoi plus lent ?
Comme expliqué dans le paragraphe précédent, le contrôle de cohérence se fait à l'écriture pour une DDL ce qui n'est pas le cas des DDS. Donc les DDS sont plus rapides à l'écriture que les DDL. Un Write sur un fichier (DDS) sera plus rapide qu'un write sur une table (DDL).
A contrario, la cohérence des données est vérifiée à la lecture pour une DDS, et aucun contrôle n'est fait à la lecture pour une DDL. Or, dans un système, il y a en général 80% de lectures versus 20% d'écritures (norme basse dans la réalité c'est 90/10).
Donc on passe 80% du temps à faire des contrôles de cohérence avec des DDS !
Fais un test :
- Prend un fichier de 1 million d'enregs et de 40 zones en cycle IPE, regarde le %CPU, le système va faire 40 millions de contrôles.
- Fais un OVRDBF vers cette fois-ci sur une table (DDL) avec les mêmes données et relance le programme, regarde le %CPU, 0 contrôles.
40 millions de contrôles versus 0 contrôles.
C'est ce que l'on t'apprends dans le cours DB2 performances.

Envoyé par m4k-Hurrican

Mieux, les DDS fournissent toujours des possibilités que DDL ne fourni pas (les Select/Omit par exemple).

Nous sommes les seuls au monde à avoir ce genre d'entités batardes non standardes.
Il faut savoir à un moment donné rejoindre la normalité.
Le monde SQL a des vues pour faire ce genre de choses et éventuellement des index dérivés qui offrent les mêmes possibilités.

Envoyé par m4k-Hurrican

Et historiquement j'ai encore de nombreux fichiers qui n'ont aucun besoin d'être réécrits (certains modules ont 10 ans et marchent très bien), et qui sont donc toujours basés sur des DDS.

Comme tu le dis HISTORIQUEMENT !!!!!
Les DDS n'ont pas évolué depuis plus de 10 ans, aucune nouveauté sur le sujet, à contrario avec les DDL les choses évoluent à chaque version : CLOB/BLOB/DATALINK/XML, rowid, timestamp automatiques, rowid, champs cachés, triggers sur colonne, MQTs etc...

Je ne dis pas qu'il faille transformer toutes les DDS en DDL (quoi que), mais au moins ne plus utiliser les DDS pour de nouveaux projets, on ne peut pas continuer à travailler ainsi, c'est à dire comme au temps du siècle dernier que sont les années 90, c'était mes vingt ans

[m4k-Hurrican]

Ok, je note bien toutes ces remarques fort intéressantes.

Envoyé par K2R400

... c'est à dire comme au temps du siècle dernier que sont les années 90, c'était mes vingt ans

Jeunot... moi c'était mes 30 !