Equivalent du #if directive de précompilation

Bonjour à tous,
Dans un script sql, j'ai un souci de compatibilité avec plusieurs versions de base à mettre en place dans une requete insert.
Pour résumer, pour des bases inférieures à un n° de version, on va dire 10 par exemple, j'ai une colonne A dans une table. Pour les bases en version 10 et plus, cette colonne n'existe plus, elle est remplacée par une nouvelle colonne B.

Dans le script je dois gérer les 2 cas, j'ai donc fait ceci (je passe le n° de version en paramètre) :

Code:

---

1 2 3 4 5

IF @Version >= 10 INSERT (..., B, ...) VALUES (..., Valeur_B, ...) ELSE INSERT (..., A, ...) VALUES (..., Valeur_A, ...)

---

Ce code ne marche pas, sql server me jette à la compil car, ou l'une, ou l'autre des colonnes A ou B n'existe pas.

En fait, c'est pas un IF qu'il me faudrait, mais l'équivalent de la condition de précompilation #IF qui existe dans certains langages.
Est-ce que ça existe en sql server, ou sinon comment faire, sachant que je n'ai pas qu'une requête dans ce cas là, pas qu'un seul script, et d'autre viendront se rajouter dans l'avenir aussi ?

Est-ce qu'il s'agit uniquement du changement du nom de colonne ou une modification fonctionnelle plus profonde ?

Je verrais bien une vue qui remplace l'accès direct à la table et dans laquelle la colonne B est renommée A dans la nouvelle version.
Et deux versions des triggers associés aux UPDATE/INSERT à compiler en fonction de la version de la base.
C'est déjà un peu moins lourd qu'une modification de chaque opération...

Dans le cas présent, sur l'ensemble des tables gérées, j'ai un renommage, de la suppression, et de l'ajout de colonnes

Sinon, et ça sera la cas le plus courant, ça sera, parfois de la suppression, mais surtout de l'ajout de colonnes, voire de tables entières.

Bon, j'ai peut-être trouvé une solution détournée. Ca sera un peu plus lourd à maintenir (moins facile à lire) et on perd l'analyse syntaxique de l'ide.

Code:

---

1 2 3 4 5

IF @Version >= 10 exec( N'INSERT (..., B, ...) VALUES (..., Valeur_B, ...) ') ELSE exec( N'INSERT (..., A, ...) VALUES (..., Valeur_A, ...) ')

---

Ce n'est pas la bonne solution quand le bout de script fait référence à des variables du script global ou des paramètres qui lui sont passés

bonjour,

Dans ce cas, il faut faire un EXEC sp_executesql afin de pouvoir passer les paramètres en question

Bon, j'ai fais différemment.
J'ai créé une variable locale type varchar, j'y ai concaténé le texte de ma requête avec les valeurs de paramètres comme ceci set toto = 'INSERT blabla' + @Monparam1 + 'blabla...', puis j’exécute le tout avec EXEC.

Hormis le fait que c'est peut-être un peu moins propre, quelle différence en terme d’exécution avec EXEC sp_executesql ?

Sur le principe, je dirais que :
1/ cette méthode est sensible aux attaques par injection SQL
2/ cette méthode génère des requêtes syntaxiquement différentes, avec donc non réutilisation des plans d'exécution.

Cependant, dans votre cas (script de migration si j'ai bien compris), vous maitrisez le contenu de la variable, donc pas de problème pour le 1/, et soit l'une soit l'autre des requêtes sera en fait exécutée, et une seule fois, vous n'êtes donc pas non plus concerné par le 2/.

Donc je ne vois pas de problème dans ce contexte précis.