Installer une procédure référençant une table qui va être modifiée [Résolu]

[Jamming Ed]

Bonjour,

Mon titre n'est peut-être pas clair, alors je m'explique.

En gros, j'ai un setup (n°2) qui va modifier la structure d'une table existante dans une base de donnée (ajout d'une colonne). A coté, j'ai un autre setup (n°1) qui va installer (installer, pas éxecuter) une procédure stockée dans la même base. Cette procédure, doit insérer des données dans la table "nouveau format".

Pour des raisons diverses et variées, il est nécessaire de passer le setup n°1 AVANT le n°2. Bien évidemment ça ne marche pas, puisque mon instruction d'INSERT référence des colonnes qui n'existent pas encore

Ma question est donc la suivante : Est-il possible de "désactiver" la vérification des objets SQL lors de l'installation d'une procédure ?

J'ai lu quelques articles sur MSDN concernant la "résolution différée des noms" mais ça à l'air de marcher uniquement pour des tables qui n'existent pas encore.

Merci de votre aide !

Jamming Ed

Merci !

[iberserk]

Passez la création de votre procédure dans le setup 2?

[Jamming Ed]

Ce n'est malheureusement pas possible dans l'état actuel des choses. Il s'agit d'une vieille version de notre progiciel (Les choses ont été améliorées depuis, ouf ).

Je crois que je vais être obligé tricher un peu et modifier ma procédure pour qu'elle crée la colonne si elle n'existe pas déjà...

Jamming Ed

[aieeeuuuuu]

et vous allez trainer ensuite cette "vérification" à chaque appel de la procédure...

Sur le même principe que la réponse d'Ibersek, pourquoi alors ne pas modifier la table dans le setup 1 ?

vous est-t-il possible de nous dire pour quelles raisons ce n'est pas faisable ? est-ce des raisons techniques, de privilèges, ou autre ?

en attendant ces précisions pour une solution optimale, vous pouvez peut être "planifier" la mise à jour de votre procédure stockée dans votre étape 1, en ajoutant par exemple un trigger DDL qui se lancera lors de la modification de la table en question.

Je vois bien d'autres solutions, des moins sales aux plus crades , mais il nous faudrait pour cela connaitre les contraintes qui vous empêchent de faire proprement

une autre solution : créer la future colonne nullable, créer votre procédure, puis supprimer la colonne... mais il ne faut pas que votre procédure soit liée au schéma...

[iberserk]

Ne modifiez pas la procédure! modifiez le script 1:

Juste avant le create procedure ajoutez la colonne si elle n'y ai pas déja...

[Jamming Ed]

OK, j'avais un peu simplifié pour essayer d'être clair, mais je vais entrer un peu plus dans les détails (j'espère que vous avez un peu de temps).

Je bosse sur l'intégration d'une application réalisée à partir un progiciel maison. Ce progiciel comporte un socle applicatif sur lequel on vient plaquer ("Publier") tout le spécifique de l'application client. Le spécifique (ou "Solution") est un gros fichier réalisé sur un EDI également maison qui permet de développer visuellement les briques de l'application. La publication consiste essentiellement à créer / modifier des tables + insérer du paramétrage et du code c# dans des tables. Il arrive également, que l'on ait besoin d'inclure dans le spécifique client des procédures stockées. Par contre, dans cette version du progiciel, ces procédures ne sont pas intégrées dans la Solution (sur les version ultérieures elles le sont). Dans mon cas, elles font donc l'objet d'un packaging séparé.

C'est ce package que j'ai appelé "Setup N°1". Le mécanisme de publication est ce que j'ai appelé pour simplifier (car ce n'est pas vraiment un setup) "Setup N°2"

L' une des nombreuses fonctionnalités du progiciel consiste à gérer ce qu'on appelle des "Catalogues". Il peuvent servir à stocker des informations comme des référentiels client ou des données statiques. Ces catalogues sont créés / modifiés graphiquement via l'EDI du progiciel. C'est donc la publication qui va créer / modifier la structure de ces tables.

Dans mon cas, la table doit être renseignée automatiquement avec des valeurs par défaut. J'utilise donc un mécanisme dit "d'After Publish" qui me permet de spécifier un certain nombre de procédures a exécuter automatiquement à la fin de la publication.

Pour résumer voici comment devrait se passer l'installation :

1. Installation de ma procédure d'insertion des valeurs par défaut (setup n°1)
2. Publication de ma solution --> modification de la table Catalogue ("setup n°2")
3. Execution de l'After Publish --> lancement de ma procédure

D'où l'interblocage...

@aieeeuuuuu > La procédure ne sera donc exécutée qu'une seule fois, après la publication. Ce que je propose n'est pas super propre, je le concède, mais pas de soucis à se faire côté performances...

Cela dit, si tu as d'autres idées, je prends avec joie !

Jamming Ed

[aieeeuuuuu]

Si votre procédure stockée n'a pour but que d'inserer des valeurs, et si elle ne doit être appelée qu'une fois après la publication, alors pourquoi ne pas exécuter directement son contenu TSQL dans la phase "after publish" ?

[iberserk]

Si votre procédure stockée n'a pour but que d'inserer des valeurs, et si elle ne doit être appelée qu'une fois après la publication, alors pourquoi ne pas exécuter directement son contenu TSQL dans la phase "after publish" ?

Tu m'enlève les mots de la bouche :-)
Et je ne comprends pas pourquoi tu dois creer ta SP avant...

[Jamming Ed]

Parce que l'After Publish ne sait qu'exécuter des procédures

J.E.

[Jamming Ed]

Finalement, un collègue vient de me souffler une idée pas trop mal :

Inclure mon insertion de données dans un une instruction SQL dynamique (sans vérification de schéma donc !).

C'est simple et ça ne ma fait pas toucher aux process d'install... Vous en pensez quoi ?

Jamming Ed

[aieeeuuuuu]

c'est exactement ce que j'allais vous proposer !

[Jamming Ed]

Coooool ! Merci pour votre aide les gars !