Mapping de schémas ?

Bonjour.

Je dois faire un transfert de certains DB depuis un serveur 2005 vers un 2008R2 (nouveau).
Cela ne devrait pas me poser de problème.

Par contre les données de ces DB sont liées à un autre DB qui reste sur le serveur 2005.
Dans le code j'ai donc souvent des expression genre "maDBCentrale.dbo.telleTable".

Est-ce qu'il m'est possible sur le serveur 2008R2 de "mapper" le nom "maDBCentrale" vers la DB qui restera sur le 2005 ?
Si oui, j'imagine que je dois passer par un Linked server ?

EDIt: ça me revient, je crois qu'il faut utiliser CREATE SYNONYM...
EDIT: Schema <> DB

Vous parlez de quoi ????

Un schéma est un objet SQL de placement logique des objets.
Le schéma par défaut dans SQL Server est le schéma dbo.

Je pense que votre notion de ce qu'est un schéma n'a rien à voir... Bref, soyez clair et précis; Utilisez les termes adéquats !

A +

J'ai corrigé mon poste. Il s'agit d'un transfert de DB sachant qu'il existe des liens vers une DB "principale" qui reste sur le serveur 2005.

J'ai "peur" de devoir créer une DB vide du même nom que la DB principale (2005) et ensuite de créer autant de synonyme dans cette DB vers l'originale qu'il y a d'object dans la DB principal.

C'est une solution : créer un serveur lié, une base vide et des synonymes pointant sur les objets de la base distantes.

Cela devrait mettre 10 minutes à se faire :
5 pour le linked serveur
5 pour tous les objets en utilisant une requête SQL dans les tables systèmes pour créer automatiquement toutes les vues .

A +

Quels seraient les objets ?

Les view, les tables, les fonctions et les procédures seulement ?

En principe oui.

A +

Ça ne marche pas.
J'ai une view avec un trigger instead of qui me permet de faire des insertions.

Dans cette view il y a une colonne n'étant liée à aucune table qui me permet l’envoi d'un paramètre lors de l'insertion

Code:

---

1 2	INSERT INTO [maView] ( colonne1, colonne2, ..., monParamètre) VALUES (valeur1, valeurs2, ..., valeurParamètre)

---

Et quand j'essaie de faire l'insert depuis le serveur distant

Code:

---

1 2 3

INSERT INTO [maView] -- Il s'agit d'un synonym ( colonne1, colonne2, ..., monParamètre) VALUES (valeur1, valeurs2, ..., valeurParamètre)

---

J'ai droit à une erreur

Citation:

---

The OLE DB provider "SQLNCLI10" for linked server "xxx.xxx.xxx.xxx" could not UPDATE table "[xxx.xxx.xxx.xxx].[schemaXXX].[dbo].[maView]" because of column "monParamètre". The user did not have permission to write to the column.

---

Une idée pour solutionner ce cas ?

Je conclu à ce silence que ce n'est finalement pas possible.

Merci quand même.

Citation:

---

Envoyé par Sergejack

Je conclu à ce silence que ce n'est finalement pas possible.

Merci quand même.

---

Est-ce que le user employé par le linked server possède les droits adéquats pour faire cette modification ?

Oui, c'est le sa sur chacun des deux serveurs.

Donc la configuration de sécurité du serveur lié vous avez défini un login distant avec sa ou est-ce que c'est un mapping avec l'utilisateur sa d'un côté et sa de l'autre ?

++

Les credentials sont les même.

Mais je vois mal en quoi avoir un mapping aurait eu une influence (quoique je ne suis plus à un étonnement près).

PS: J'insiste que "tout" fonctionne à l' "exception" de l'insertion dans cette view quand la colonne virtuel se voit assignée une valeur autre que NULL (qui n'est pas une valeur, je sais).

La colonne de destination ne serait elle pas une colonne identity ou une colonne calculee? (celle referencee par votre vue)

Cette colonne (dont je disais qu'elle était virtuelle et servait à la paramétrisation) est une colonne calculée.

Code:

---

CAST(NULL AS BIT)

---

Ok vous avez donc votre réponse.

Citation:

---

Mais je vois mal en quoi avoir un mapping aurait eu une influence (quoique je ne suis plus à un étonnement près).

---

Simplement ici si vous utilisez un mapping sa -sa et que vous êtes loggé avec un autre utilisateur vous auriez pu avoir ce genre d'erreur. Le choix du login distant à contrario permet d'impersonnaliser la connexion pour l'ensemble des utilisateurs du serveur source. Mais bon votre problème était bien ailleurs.

++

Est toujours bien ailleurs, hélas.

Si quelqu'un pense à une autre approche il m’intéresserait de l'entendre.