Interrogazione senza dover specificare lo schema della tabella


10

Ho importato un sacco di tabelle da SQL Server 2000 al mio database del 2008. Tutti i tavoli importati sono prefissati con il mio nome utente es erpadmin.tablename.

Nelle proprietà della tabella elenca 'erpadmin' come schema db. Quando scrivo una query ora devo includere "erpadmin". di fronte a tutti i nomi delle tabelle che sono confusi.

Risultato attuale:

select *
from erpadmin.tablename

Risultato desiderato:

select *
from  tablename

Risposte:


23

Se si desidera tornare a utilizzare lo schema dbo come in SQL Server 2000, è possibile spostare nuovamente la tabella nello schema dbo:

ALTER SCHEMA dbo TRANSFER erpadmin.tablename;

Un'alternativa se ti piace avere lo schema non dbo è quello di impostare lo schema predefinito dell'utente, erpadminquindi se non specifichi uno schema, lo utilizzerà come predefinito. (I membri del ruolo predefinito del server sysadmin ignorano DEFAULT_SCHEMAe utilizzano dboper impostazione predefinita.)

ALTER USER erpadmin WITH DEFAULT_SCHEMA = erpadmin;

Il nome in due parti che hai (schema.table) è una buona abitudine da prendere in considerazione, quindi puoi essere esplicito con quale tabella ti riferisci. Alcune funzioni richiedono l'uso di un nome in due parti, le viste indicizzate ne sono un esempio.


17

Questo è un caso classico del motivo per cui è necessario specificare il nome dello schema quando si accede agli oggetti del database. Quando non è specificato e stai tentando di accedere a un oggetto in uno schema non predefinito, allora ti imbatterai nel problema che stai vedendo in questo momento.

La vera soluzione è quella di cambiare la tua applicazione (o qualsiasi agente di query che hai in questo momento causando il problema) per essere esplicito.

Quando scrivo una query ora devo includere "erpadmin". di fronte a tutti i nomi delle tabelle che sono confusi.

Non è confuso, è una convenzione di denominazione esplicita . Vi consiglio di attenervi a quella nomenclatura per evitare lo spostamento degli oggetti e le incoerenze.


3
Un altro motivo per utilizzare sempre nomi in due parti è evitare la situazione in cui più utenti eseguono lo stesso codice (ad esempio select ... from table5 ;) e ottengono risultati diversi. Ciò è negativo per la memorizzazione nella cache del piano e anche per la risoluzione dei problemi (persona dell'assistenza, "la query funziona correttamente qui"). Inoltre, la combinazione di schemi, necessaria per l'indicizzazione di funzioni e viste, richiede due nomi di parti. TLDR: smetti di essere pigro - usa due nomi di parti.
Greenstone Walker,

7

Oltre alla risposta di @AdamWenger. Per creare script per il trasferimento in un altro schema è possibile utilizzare il seguente script

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'

4

Il tuo problema è probabilmente dovuto al modo in cui è stata eseguita la migrazione. Roba non dovrebbe essere allegata al tuo utente, a meno che tu non sia considerato il proprietario.

Gli schemi sono lì per aiutarti a separare le tabelle da qualunque cosa abbia senso. Supponiamo di avere una tabella di risorse per il dipartimento Risorse umane e di volerne una separata per il reparto produzione, mantenendo entrambi sullo stesso database. In tal caso è possibile avere due tabelle denominate risorse, una nello schema di produzione e un'altra nello schema delle risorse umane. Ecco perché è necessario specificare shcemas, a meno che non si introducano elementi nello schema predefinito.

Se non stai ripetendo la migrazione per qualche altro motivo, il trasferimento di Adam Wenger dovrebbe essere un'opzione saggia.


-2

Inizia il tuo comando con La USE [tablename] tua query non ha un database associato a cui fare riferimento e il database che stai guardando non è il valore predefinito per l'utente che ha effettuato l'accesso Nella parte superiore della finestra della query probabilmente dice "master"


3
Intendi [database_name]vero?
dezso
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.