Problème user/schéma après restauration

Bonjour à tous,

depuis quelques jours et la restauration d'une base de données (MSSQL 2005), une de mes applis ne parviens plus à insérer ou updater des données dans ladite base.

L'appli en question utilise le compte super admin de l'instance SQL et les requêtes qu'elle effectue sont extrêmement simples :

Code:

---

INSERT INTO [dbo].[maTable] ...

---

La base de données a donc été restaurée hier et depuis, à chaque appel de la requête ci-dessus, j'obtiens le message :

Citation:

---

Nom d'objet 'dbo.maTable' non valide.

---

Dans Management Studio, si je teste la même requête sans le schéma dbo devant le nom de la table, l'insert fonctionne.

Je ne comprends pas ce qui a pu se passer. Auriez-vous une idée de la cause du problème et éventuellement un moyen pour le résoudre ?

D'avance merci.

Bonjour,

Quel compte de connexion utilisez vous quand vous dites superadmin ?
Est ce le compte sa ou un compte de connexion (et utilisateur) que vous utilisez ?

++

MikeDavem, par SuperAdmin j'entendais bien "sa".

Bonjour,

As-tu restauré sur le même serveur ?

Une piste :
Si les collations ne sont pas les mêmes, il se peut que les requêtes ne fonctionnent plus car la casse des objets n'est pas la bonne...

La restauration a bien eu lieu sur le même serveur.
La collation n'a pas changé.

Une piste peut-être : sur la même instance SQL, j'avais une copie de la base de prod (avant restauration) dont je me servais pour des tests.
Celle-ci n'a pas été restaurée et ne pose aucun problème.

Schéma ou pas, les requêtes passent sans problème.

:?

une autre piste alors :

La base par défaut pour "sa" était sur la base restaurée, et depuis la restauration ça n'est plus le cas depuis la restauration.
Si ton appli ne sélectionne explicitement pas la base en question...

Est-ce que c'est la seule requete qui ne fonctionne pas ? ou est-ce que les autres requêtes de ton appli te donnent la même erreur ?

aieeeuuuuu, merci pour ton aide.

Alors, voila le contexte complet :
- la bdd en question est la base d'une appli métier sur laquelle j'ai ajouté quelques procs stocks pour insérer ou mettre à jour des données dans 4 tables (et uniquement celles-ci)
- toutes les requêtes dans les procs stock utilisent cette forme : [dbo].[maTable]

J'ai essayé de supprimer le [dbo] dans toutes les proc stocks mais j'ai le même message d'erreur.

En comparant les autorisations sur les quatre tables par rapport à la base de test, je me suis aperçu que tous les rôles existant sur la base de test (pour ces 4 tables) sont absents des tables de la base de prod.
J'ai ajouté les mêmes autorisations à la mano mais rien n'y a fait.

Concernant l'appli qui attaque la base de prod, il s'agit en fait d'un webservice.
La base attaquée est donc définie dans le fichier de config du webservice.
Rien n'a changé du côté de cette appli.

Quel est le propriétaire de la base ?

Code:

---

1 2 3 4 5

SELECT db.name AS DATABASE_NAME, sp.name AS OWNER_NAME FROM sys.databases AS db INNER JOIN sys.server_principals AS sp ON db.owner_sid = sp.sid

---

Si c'était un compte SA et que vous avez effectué la restauration en rentrant dans SSMS sous un compte windows (ou l'inverse), ce, comportement est normal.

Dans ce cas, changez le propriétaire de la base !

Code:

---

EXEC sp_changedbowner ...

---

A +

Merci pour votre réponse.

Le propriétaire de la base de prod (comme de la base de test) est 'sa'.

Définitivement, je ne comprends pas ce qui ne va pas.

peut être avez vous un problème de recollement de sid ?

http://blog.developpez.com/sqlpro/p9...sse-et-compte/

http://blog.developpez.com/sqlpro/p8...-utilisateurs/

A +

Merci à vous deux pour votre aide.
Je viens enfin de comprends l'origine du problème. Nulle question de droit ou de schéma ici, l'utilisateur ayant effectué la restauration a en fait modifié un caractère dans le nom de la base...:oops: