merci de ta réponse
c'est vrai que j'ai pas bien expliqué la raison d'éviter le SQL dynamique
entre mon serveur central et mes serveurs locaux j'ai bcp de tables à mettre à jour, via plusieurs proc stock.
Les enregistrements a mettre a jour sont flagués par une colonne "tobeUpdated".
Si je veux vérifier qu'une table a besoin d etre mise a jour je dois faire un
select count(*) from [SERVEUR].[Base].[user].table where tobeUpdated = 1
Si je le fais en sql dynamique, pour récupérer ma valeur de count j'ai besoin de la mettre dans une table temporaire ( http://www.developpez.net/forums/viewtopic.php?t=465026 ), ce que je voudrais éviter car ça me fait modifier toutes mes procs stocks (pour le count et pour la lecture via un curseur des enregistrements...)
Ca représente une trop grosse mise à jour
Quoi qu'il en soit, on a trouvé une autre solution intermédiaire : Les procs Stocks de mises à jour sont présentes sur les serveurs Locaux, et appelées par le serveur Central... et vont mettre à jour le serveur central.
C'est un peu tordu mais après un petit test ça a l'air de tourner plutot bien.
1 2 3
| exec [serveurLocal1].[base].[user].MiseAJourCentral
exec [serveurLocal2].[base].[user].MiseAJourCentral
... |
donc je dois bien écrire 1 ligne par serveur local, mais pas plus (le contenu du traitement étant effectué sur le serveur local qui n'a besoin que d'1 adresse : celle du central)
Partager