Interroger sans avoir à spécifier le schéma de la table

J'ai importé un tas de tables de SQL Server 2000 vers ma base de données 2008. Toutes les tables importées sont préfixées avec mon nom d' utilisateur , par exemple: erpadmin.tablename.

Dans les propriétés du tableau, il répertorie «erpadmin» comme schéma de base de données. Lorsque j'écris une requête, je dois maintenant inclure «erpadmin». devant tous les noms de table ce qui est déroutant.

Résultat actuel:

select *
from erpadmin.tablename

Résultat désiré:

select *
from  tablename

Si vous souhaitez revenir à l'utilisation du schéma dbo comme vous l'étiez dans SQL Server 2000, vous pouvez replacer la table dans le schéma dbo:

ALTER SCHEMA dbo TRANSFER erpadmin.tablename;

Une alternative si vous aimez avoir le schéma non-dbo est de définir le schéma par défaut de votre utilisateur, erpadminpuis si vous ne spécifiez pas de schéma, il l'utilisera par défaut. (Les membres du rôle serveur fixe sysadmin ignorent DEFAULT_SCHEMAet utilisent dbopar défaut.)

ALTER USER erpadmin WITH DEFAULT_SCHEMA = erpadmin;

Le nom en deux parties que vous avez (schema.table) est une bonne habitude à prendre cependant, vous pouvez donc être explicite avec quelle table vous faites référence. Certaines fonctionnalités nécessitent que vous utilisiez un nom en deux parties, les vues indexées en sont un exemple.

Il s'agit d'un cas classique de la raison pour laquelle vous devez spécifier le nom du schéma lors de l'accès aux objets de base de données. Quand il n'est pas spécifié et que vous essayez d'accéder à un objet dans un schéma non par défaut, vous allez rencontrer le problème que vous voyez en ce moment.

Le vrai correctif consiste à modifier votre application (ou tout autre agent d'interrogation dont vous disposez actuellement, à l'origine du problème) pour être explicite.

Lorsque j'écris une requête, je dois maintenant inclure «erpadmin». devant tous les noms de table ce qui est déroutant.

Ce n'est pas déroutant, c'est une convention de dénomination explicite . Je vous recommande de vous en tenir à cette nomenclature pour éviter le brassage d'objets et les incohérences.

En plus de la réponse @AdamWenger. Pour créer des scripts pour le transfert vers un autre schéma, vous pouvez utiliser le script suivant

select 'ALTER SCHEMA dbo TRANSFER '+s.name+'.'+t.name
from sys.schemas s
     join sys.tables t on t.schema_id=s.schema_id
where s.name='erpadmin'

Votre problème est probablement dû à la façon dont la migration a été effectuée. Les éléments ne doivent pas être attachés à votre utilisateur, sauf si vous êtes considéré comme le propriétaire.

Les schémas sont là pour vous aider à séparer les tables par n'importe quel sens. Supposons que vous ayez une table de ressources pour le département RH et que vous en vouliez une autre pour le département de production, tout en conservant les deux dans la même base de données. Dans ce cas, vous pouvez avoir deux tables nommées ressources, une dans le schéma de production et une autre dans le schéma HR. C'est pourquoi les shcemas doivent être spécifiés, sauf si vous introduisez des éléments dans le schéma par défaut.

Si vous ne refaites pas la migration pour une autre raison, le transfert d'Adam Wenger devrait être une option judicieuse.

Lancez votre commande avec le USE [tablename] Votre requête n'a pas de base de données associée à référencer et la base de données que vous regardez n'est pas la valeur par défaut pour l'utilisateur connecté En haut de la fenêtre de requête, il est probablement dit "maître"