Existe-t-il un concept de «fichier inclus» dans SQL Server?

J'ai un ensemble de scripts qui doivent être exécutés dans un certain ordre. Je voudrais créer un "fichier maître" qui répertorie tous les autres fichiers et leur ordre correct. Fondamentalement, comme un fichier include de C ++ ou ASP / VBScript.

Si vous utilisez SQLCMD , vous pouvez utiliser :r FileNamepour inclure un fichier .sql distinct.

: r FileName

Analyse les instructions T-SQL supplémentaires et les commandes SQLCMD du fichier spécifié par FileName dans le cache d'instructions. FileName est lu par rapport au répertoire de démarrage de Visual Studio. Le fichier est lu et exécuté après avoir rencontré un terminateur de lot. Vous pouvez exécuter plusieurs commandes: r. Le fichier peut inclure n'importe quelle commande SQLCMD, y compris le terminateur de lot défini dans Outils, Options. Vous pouvez utiliser: r dans un script de pré-déploiement ou de post-déploiement pour inclure d'autres scripts.

Dans le sens des anciens préprocesseurs C, certainement pas

• T-SQL en soi n'a pas un tel concept
• sqlcmd et sqlcmdmode de SSMS ne gèrent pas les chemins d'accès relatifs aux fichiers
• sqlcmd et sqlcmdmode de SSMS ne prennent pas en charge le conditionnel, y compris

Si vous avez un ensemble de fichiers avec des chemins absolus donnés, que vous souhaitez inclure dans un ordre inconditionnel, vous pouvez utiliser l'outil de ligne de commande sqlcmd ou utiliser SSMS dans sqlcmdmode comme mentionné par @mfredrickson et @Marian.

Mais si vous voulez des chemins relatifs ou des inclusions conditionnelles, vous devez utiliser un wrapper appelant sqlcmd (ou l'un de ses prédécesseurs obsolètes isql ou osql).

Actuellement à mon travail dans cette situation, je suis en train de revoir et d'étendre le vieux code vbs et hta. Je ne suis pas complètement satisfait, mais c'est une décision pragmatique. Il fonctionne et l'utilisateur final est à la maison avec l'interface graphique hta et aucune installation de logiciel supplémentaire n'est requise.

Pour une nouvelle conception, je commencerais à penser à utiliser WPF et PowerShell pour encapsuler les appels de sqlcmd, mais avec nos clients actuels, je ne peux pas présumer la présence de PowerShell V2.

Dans les temps anciens, nous écrivions des lots cmd simples à cet effet, certains d'entre eux étant encore utilisés.

Je suppose qu'il existe des outils actuels, en particulier ceux ciblant les workflows, qui pourraient convenir ici. Je ne les connais pas.

En plus du mode SQLCMD dans Management Studio, vous pouvez également utiliser un fichier de commandes à utiliser comme fichier maître pour organiser et appeler tous vos fichiers SQL à l'aide de l' utilitaire SQLCMD .

Le mode SQLCMD est une simulation de l'utilisation des utilitaires dans Management Studio, il n'y a donc pas de grande différence entre les modes. Sauf que parfois je préfère exécuter des batchs (plus d'ouverture de M Studio ... chargement de db correct ... etc). Je préfère tout configurer dans le lot, y compris les fichiers de sortie.

Je suis d'accord, un préprocesseur T-SQL est absolument nécessaire. J'ai développé mon propre en C #, ce qui m'a pris environ une heure. Outre le contrôle de l'ordre d'exécution des scripts SQL, cela me permet également d'avoir des macros qui ressemblent à des FDU scalaires et qui sont pratiques à utiliser, mais qui fonctionnent aussi rapidement que des FDU en ligne.

J'aime la réponse de bernd_k . Selon la façon dont vous avez nommé vos scripts, comme l'inclusion d'un nombre, SQL Server PowerShell (SQLPS) peut être utilisé si vous exécutez SQL Server 2008 ou une version ultérieure. Ensuite, même si vous utilisiez SQL 2005, vous pourriez utiliser PowerShell et le SMO pour 2005.

Note latérale: Je crois que SQLCMD sera finalement mis sur la liste dépréciée et sera remplacé par SQLPS, PowerShell.

Il existe également quelques autres options.

1. Configurez chaque script en tant qu'étape dans un travail de l'Agent SQL. Vous pouvez définir l'ordre d'exécution.
2. Créez un package SSIS pour appeler chaque fichier. Cela peut offrir un peu plus de contrôle et offrir un peu plus d'options de journalisation. J'aime cette méthode si le résultat d'un script doit être vérifié avant l'exécution du suivant.