Existe-t-il un moyen de valider facilement qu'un script SQL est compatible avec une version spécifique de SQL Server?
Je travaille actuellement sur un projet qui doit fonctionner dans différents environnements SQL. La plupart de mes développeurs ont SQL Server 2017. L'application s'exécute dans SQL Azure et le client a récemment commencé à exécuter certains environnements à l'aide de SQL Server 2016. Le projet utilise SSDT pour générer des fichiers Dacpac qui fonctionnent correctement à des fins de développement, mais nous avons récemment exécuté dans un cas où un développeur a utilisé une fonction système introduite en 2017. Les scripts de procédure stockée qui faisaient référence à cette fonction ont bien fonctionné dans nos environnements de développement et Azure et ont échoué dans l'environnement de 2016.
Existe-t-il un moyen simple de valider un script par rapport à une version arbitraire de SQL Server, sans nous obliger à créer plusieurs environnements de test pour chaque version de SQL Server que nous souhaitons prendre en charge? Il n'est pas nécessaire que la méthode soit 100% infaillible, mais elle devrait résoudre la grande majorité des problèmes de compatibilité potentiels.
Il n'y a pas d'outil simple ou de script existant à ma connaissance. En termes d'analyse de l'utilisation de fonctions ajoutées dans une version spécifique (ou activée par un niveau de compatibilité spécifique), quelque chose pourrait être écrit à l'aide de la documentation de MS, mais cela pourrait ne pas intercepter les appels via SQL ad hoc si votre procédure stockée et toute autre utilisation ce modèle pour quoi que ce soit, et vous devrez effectuer des recherches supplémentaires pour couvrir les modifications apportées aux fonctions non documentées.
sans nous obliger à créer plusieurs environnements de test pour chaque version de SQL Server que nous souhaitons prendre en charge?
Ne serait-il pas acceptable de tester par rapport à la version minimale que vous devez prendre en charge, plutôt que de tester par rapport à toutes les versions à partir de là? Ce ne serait qu'une seule instance supplémentaire que vous devez ajouter à votre CI/Test/autres processus. Si 2016sp1 est la première version que vous devez prendre en charge, presque tout est disponible dans toutes les éditions afin que vous puissiez utiliser Express et ne pas avoir de frais de licence pour cette seule instance. Vous pourriez également vous en sortir avec les versions précédentes, si vous n'utilisez aucune fonctionnalité standard/entreprise uniquement avant 2016sp1.