Discussion :

[echec71]

Bonjour,
je tente de transformer un certain nombre de fichiers DDS en table SQL..
Je suis la méthode donnée par VOLUBIS (en résumé)
1-Conversion des fichiers physiques en tables SQL
2-Création d'un logique DDS ayant le même format que l'ancien physique
Cela fonctionne très bien sur certains fichiers le niveau de format du logique DDS étant bien le même que celui de l"'ancien" physique. les programmes fonctionnent toujours.
Mais je rencontre un problème lors de la transformation de certains fichiers qui ont été modifiés afin d'jouter une colonne de type "Identity" via un alter table.
Lors de la création du logique pointant sur table SQL via le code suivant (CRTLF)
A UNIQUE
A R RFIC PFILE(TABLE_SQL)
A FORMAT(FICHIER_DDS)
A K CLE
Le logique ainsi créé ne conserve pas le même identificateur de niveau de format que le fichier d'origine. Contrairement aux fichiers qui n'ont pas de colonne de type "Identity"
Le code suivant permet de conserver l'identificateur de niveau de format....
A UNIQUE
A R RFIC PFILE(TABLE_SQL)
A FORMAT(TABLE_SQL)
A K CLE
Mais un ajout de colonne sur la table sql sera répercutée sur le logique et viendra modifier l'identificateur de niveau de format.
Avez vous déjà rencontré ce problème ? Comment le contourner ?
D'avance merci

[larry57]

Bonjour,

Personnellement, j'ai créer un outil pour gérer ce genre de problème.
Mon programme génère un script qui va remplacer les tables, les sauvegarder, mettre les logiques et compiler les programmes tout seul.
Avec ça, pas de soucis.
Je t'invite à faire de même.

Stéphane

[echec71]

Bonjour,

Personnellement, j'ai créer un outil pour gérer ce genre de problème.
Mon programme génère un script qui va remplacer les tables, les sauvegarder, mettre les logiques et compiler les programmes tout seul.
Avec ça, pas de soucis.
Je t'invite à faire de même.

Stéphane

Merci pour votre réponse mais le but était d'éviter de recompiler les programmes existant, ce qui devrait être possible si l'identificateur de niveau de format du fichier logique reste identique à l'ancien fichier physique.
Le script de transformation est écrit et est fonctionnel sauf pour les tables avec une colonne de type "Identity" ou le logique généré ne garde pas l'identificateur de format de l'ancien fichier.
Il faudrait alors recompiler tous les programmes utilisant ces fichiers ce que je souhaitais éviter afin de simplifier le plus possible cette migration.
c'est pourquoi je cherche à créer un logique avec un même identificateur de format que la table SQL qui contient une colonne de type "Identity"

D'avance merci

claude

[m4k-Hurrican]

Bonjour.
Ce que tu demandes est impossible.
Le niveau de format est justement fait pour contrôler si un champ a été modifié dans la structure du fichier.
Ajouter une colonne donnera forcément un niveau de format différent.

[echec71]

Bonjour.
Ce que tu demandes est impossible.
Le niveau de format est justement fait pour contrôler si un champ a été modifié dans la structure du fichier.
Ajouter une colonne donnera forcément un niveau de format différent.

Bonjour,
En fait le logique ne pointe que sur les champs d'origine du fichier DDS, Ceci est obtenu en les nommant directement dans le logique.
Celui ci ne verra donc pas les champs qui pourront être ajouter par la suite dans la table SQL.
Ceci fonctionne très bien sauf que je n'arrive pas à créer un fichier logique avec le même niveau de format si un champ de type identity est présent dans la table d'origine.
Pour les autres fichierss cette méthode fonctionne très bien.

[m4k-Hurrican]

Bonjour,
En fait le logique ne pointe que sur les champs d'origine du fichier DDS, Ceci est obtenu en les nommant directement dans le logique.
Celui ci ne verra donc pas les champs qui pourront être ajouter par la suite dans la table SQL.
Ceci fonctionne très bien sauf que je n'arrive pas à créer un fichier logique avec le même niveau de format si un champ de type identity est présent dans la table d'origine.
Pour les autres fichierss cette méthode fonctionne très bien.

OK je comprend mieux.
Mais je pense que le problème est qu'un champ identity ne peut être omis du fichier. C'est l'identifiant de l'enregistrement.
Même si tu ne le met pas dans ton DDS, il sera probablement inclus de manière "cachée". Surtout, et c'est généralement le cas, si c'est la clé primaire.

Personnellement, parce que j'en ai la possibilité, je vérifie, modifie, et recompile tout (surtout que nous avons du RPG standard, des programmes en VB.net et d'autres en PHP). Ce qui peut être lourd, mais les gains sont appréciables.

[larry57]

bonjour,

Le mieux, c'est dans ton cas de te faire tes outils.
Faire un programme qui te génère des scripts de compilations à partir d'une table est très simple.
Créé toi un référentiel que tu vas utilisé par la suite dans tes scripts.
C'est quelque chose que tu utilises une fois et que tu réutiliseras souvent.

Stéphane