Execution SQL - Check Release OS

[bvaron]

Bonjour,

Une petite question qui me taraude.
Est-ce qu'il est possible d’exécuter un script SQL en spécifiant une version OS pour qu'il puisse nous dire si certain ordres ne sont pas pris en charge dans la version spécifiée ?

Par exemple, je développe sur une V7R3, je désirerais savoir si mon script SQL est compatible avec la V7R1.

Merci pour votre aide.

[nbonnet]

Bonjour,

Dans un script SQL tu peux faire ce genre de contrôle :

Code : Tout sélectionner

create variable nb.os char(4) ;
set nb.os = '7.5' ; -- A remplacer par recherche de version 

begin
  case nb.os 
    when '7.5' then call qcmdexc('crtdtaara nb.ver75 *char') ;
    when '7.4' then call qcmdexc('crtdtaara nb.ver74 *char') ;
    when '7.3' then call qcmdexc('crtdtaara nb.ver73 *char') ;
    else signal sqlstate 'VRM00' set message_text = 'Version non supportée !' ;
  end case ;
end ; 

Cela force à passer par des curseurs et pas des select en direct par exemple

[bvaron]

Merci Nathanaël,

Cette astuce me permet de rédiger mon code SQL en fonction de la version.
Pour info, mes scripts passent par un parseur maison avant d'être exécuté, je peux intégrer des macros qui font ça.

Ce que je comprends, c'est que le meilleur moyen est de passer mon script sur une machine à la version cible et de relever toutes les erreurs.

Je m'en doutais un peu, je me suis dit "sait-on jamais"

Merci en tout cas,

Bonne journée.

[Hurri]

Bonjour,

Je n'ai pas testé, mais est-ce qu'une tentative de sauvegarde de l'objet concerné en version 'x' (dans un SAVF par exemple) ne fournirai pas déjà une indication de la compatibilité ou non ?
Par exemple si tu as une procédure appelé called_Prc, qu'elle soit SQL ou externe, elle est stockée sous ce nom dans la bibliothèque. Si c'est une procédure externe, la procédure fait 'partie' de l'objet lui même (RPGLE ou autre).
Il te suffit de faire un SAVOBJ de l'objet called_Prc dans un SAVF bidon, en version 'x' (paramètre TGTRLS), et normalement, si ce n'est pas compatible, tu auras un message d'erreur. Ensuite il faut chercher ce qui n'est pas compatible, et là c'est une autre histoire.

[bvaron]

Bonjour Hurri,

Effectivement, il va falloir se pastiller le code de toute façon, c'est que mon script est plutôt ... gros .

La meilleure solution est de tester cette génération sur une machine avec la version ciblée.
J'ai une partition encore en V6R1, je vais lancer une génération automatique tous les soirs pour m'alerter si une erreur survient.

Merci pour ton aide.

[Hurri]

Pense, lorsque tu crées la procédure, à indiquer la version de destination dans "set option".
Personnellement, même des options apparues en V7R4, arrivent à passer en V7R2.
Mais il faut que j'ai indiqué la bonne version lors de la création de la procédure.
Si je laisse V7R4 à la création, il refuse ensuite de les descendre en V7R2. Je recrée alors la procédure via ACS, en choisissant l'ancienne procédure, puis clic-droit, "nouveau" -> "basé sur", et je modifie la version. Là çà passe. Peut-être que certaines nouveautés ne sont pas "adaptables" aux anciens OS, mais celles que j'utilise, comme le 2ème paramètre des TRIM le sont.

[bvaron]

Haaaa, excellent,

Code : Tout sélectionner

Set Option TgtRls=VxRxMx

.. je ne la connaissais pas celle-ci.

Merci pour l'info, super merci.

Bon week-end.

[Hash]

Bonjour,

En règle générale, il n'existe pas de fonctionnalité intégrée dans les systèmes de gestion de bases de données pour tester directement la compatibilité des scripts SQL avec différentes versions d'un OS. Cependant, il y a des approches que vous pouvez envisager :

Rechercher les changements de fonctionnalités entre les versions : Consultez la documentation pour identifier les modifications ou les nouvelles fonctionnalités introduites dans les versions plus récentes. Cela peut vous aider à anticiper les problèmes de compatibilité.

Utiliser un environnement de test : La meilleure manière de s'assurer de la compatibilité est de tester le script sur un système avec la version cible de l'OS.