J'ai un projet avec de nombreuses procédures, fonctions, vues et tables stockées.T-SQL: Accéder aux objets DB dans le même schéma sans qualification?
J'ai actuellement le projet déployé dans une base de données tous dans le même schéma. Pour cet exemple, nous l'appellerons "mainproject"
Maintenant, j'ai été chargé de créer un projet en double dans la même base de données. La solution évidente est de cloner tous les objets dans un autre schéma. J'ai été capable de le faire en utilisant des scripts SQL. J'ai maintenant un autre schéma appelé "secondproject" contenant tous les objets du premier schéma. Le problème est que, dans toutes mes fonctions, vues et procédures, le schéma original est référencé, par ex. Par conséquent, l'exécution des fonctions finit par référencer le schéma incorrect. Parcourir des centaines de vues, procs et fonctions pour trouver et remplacer toutes les occurrences du schéma mainproject serait un processus fastidieux et potentiellement non fiable.
Ma question est, est-il un moyen de spécifier "dans le schéma actuel" lors du référencement de tout objet?
Juste en faisant DECLARE @someVar INT = getId(@someObject) résultats dans 'getId' is not a recognized built-in function name. et je ne peux même pas enregistrer la procédure.
EDIT: La première réponse ci-dessous aide à jeter un peu de lumière sur la situation. Si vous ne spécifiez pas de schéma sur l'accès à un objet, il suppose qu'il se trouve dans votre schéma par défaut.
Le problème est que sur le serveur de production sur lequel je vais exécuter mon script DDL, le schéma par défaut du serveur pour mon compte d'utilisateur est dbo. L'utilisateur de l'application n'a accès qu'aux instructions DML. Je ne peux donc pas utiliser ce compte pour exécuter le script de création.
Je suppose que s'il n'y a pas moyen d'avoir une procédure stockée suppose des objets non qualifiés sont dans le même schéma, il réside dans, je vais devoir recourir à trouver/remplacer après avoir généré un script ....
Oui, vous avez raison, je parlais de schémas. Il semble que vous ayez raison, le problème est que je suis en train de développer sur le serveur sous "mon" compte, dont le schéma par défaut est 'dbo'. Je vais essayer de créer un autre compte utilisateur dans la base de données pour développer sous avec le jeu de schéma par défaut. – fdmillion
Ok, le problème que j'ai découvert est que cela fonctionnera bien pour mon instance locale, mais pas pour le serveur de production. Je ne reçois qu'un seul compte utilisateur, avec son schéma par défaut sur la base de données unique définie sur 'dbo'. L'utilisateur de l'application que l'administrateur a créé n'a que l'accès aux instructions DML, donc je ne peux pas l'utiliser pour exécuter les requêtes DDL pour créer la base de données. Étant donné que SQL Server ne me laisse même pas créer des procédures stockées qui référencent des objets qu'il ne croit pas exister, je suis toujours bloqué ... – fdmillion
Je suppose que vous pouvez rendre toutes vos requêtes dynamiques SQL, avec la partie dynamique étant le schéma . Je pense que c'est probablement plus d'effort et plus de désordre que juste trouver et remplacer le schéma et l'exécuter après. Ne pas pouvoir avoir plusieurs connexions pour vous rendra cela très difficile. –