Y a-t-il un moyen facile de créer des synonymes vers toutes les tables dans une base de données différente?
merci
EDIT: J'ai un certain nombre de procédures stockées qui ont obtenu des schémas de table dans les requêtes SELECT. Lorsque je copie les schémas sur un nouveau serveur, le SPS échoue car le schéma n'existe pas. Il y a peu de contrôle que j'ai sur le serveur de destination et je ne veux pas avoir à changer tout le SP, alors je pensais que Synonyme peut être une bonne solution.
3 Réponses :
S'il s'agit d'une instance unique , et les deux Les bases de données sont sur elle - utilisez trois noms de noms: Si l'autre base de données existe sur une instance SQL Server distincte (vous pouvez avoir plusieurs serveurs SQL sur une boîte), ou la base de données existe sur une instance SQL Server sur une boîte différente / vm - Créez A Server lié instance. Ensuite, vous utilisez quatre noms de noms:
Pas tout à fait le scénario ici, s'il vous plaît voir mon édition. Désolé, j'aurais dû être plus explicite.
Vous pouvez exécuter une requête comme celle-ci sur la base de données d'origine, puis exécutez les résultats de sortie sur votre nouvelle base de données. À titre d'exemple, en cours d'exécution contre la base de données principale produirait: < / p>
+1 pour cette réponse. @Joe Stefanelli, où diriez-vous le SQL généré?
Je l'ai eu, courez-les sous la db que vous voulez que le synonyme soit.
Créer une procédure stockée quelque chose comme ceci: puis exécutez-le comme ceci: Notez que vous devez exécuter ceci En tant qu'utilisateur avec le privilège de créer des synonymes. Si vous voulez un utilisateur sans ces privilèges qui l'exécutent, dans SQL 2000, pas de chance, dans SQL 2005, vous pouvez mettre un exécution sous forme de clause.
+1 pour cette approche SP. @Erike, lorsque vous l'appelez à nouveau pour refléter de nouvelles mises à jour, vous aurez des problèmes. C'est-à-dire que vous devez utiliser la chute et créer à chaque fois que vous souhaitez modifier un synonyme;
@Xpt absolument vrai. goutte si déjà existant est requis. Un exercice pour le lecteur.
Ajout de l'instruction DROP pour les lecteurs occupés là-bas: p SELECT @SQL = 'Si vous n'existe pas (SELECT * à partir de SYS.SYNONNONS où nom =' '+ TABLE_NAME +' '' et Object_ID (base_object_name) n'est pas null) Drop Synonyme "+ Table_Name + 'Créer synonyme' + Table_Name + 'pour' + @Database + '.' ' + @Schema + '.' + Table_Name à partir de #tables où tabledId = @ID
@kuklei Il semble que vous voudriez déposer le synonyme de n'importe quel cas, pas seulement si le nom de base_object_ est existé?
Ne répond pas à ma question de configuration de la base de données. Lorsque vous accédez à la base de données, la chaîne de connexion est-elle identique autre que la base de données / catalogue? Le nom d'hôte / IP et le port sont-ils identiques?
Si le SPS échoue au manque de schéma, pourquoi ne pas créer le schéma manquant? Mais les SPS peuvent-ils fonctionner dans les nouvelles tables d'installation, etc.?
C'est une sorte de longue histoire. Le développement est destiné à s'appuyer sur une application de vente au détail, qui utilise son propre schéma personnalisé choisi au moment de la mise en place. Donc, l'extension, que j'ai héritée, utilise SP qui fait référence à quelque chose comme RetailProduct.table1. Le problème est que ce schéma est différent de Dev à la production. Donc, je suis curieux s'il est préférable de créer un synonyme pour chaque détaillantProduct.Tablex. Ce serait le cas exact d'un serveur lié si les données d'extension sont créées dans une base de données distincte. Mais ce n'est pas. Les tables et SPS sont intégrés à la même dB que le produit de vente au détail.
Un schéma personnalisé irait bien ... Si la configuration itère sur toutes les références pour les conserver en synchronisation. N'a toujours pas eu une réponse définitive concernant la configuration, mais ne sonne pas comme des serveurs liés sont la solution ...