L'altro giorno mi è successa una cosa apparentemente strana. Una di quelle cose che quando capitano, se non ci si pensa abbastana, vengono definite dalla frase "MA E' IMPOSSIBILE!!" .
Vi illustro la situazione:

una semplice stored procedure che esegue una select su di una tabella.
Procediamo per step.
Come prima cosa, accedo su di un database con il mio utente, che a sua volta ha dbo come default schema.
SQL Server accede agli oggetti con la seguente logica:

1) Tenta di accedere allo schema di default
2) Tenta di accedere all'oggetto sotto dbo.

Prendiamo la seguente query di esempio:

SELECT * FROM Movimenti

Per accedere alla tabella Movimenti con un ipotetico utente User1 che ha come default schema Schema1, SQL server tenterà prima di accedere all'oggetto Schema1.Movimenti e poi, se non è stato trovato, a dbo.Movimenti.

Detto questo (ricordiamoci che il mio utente ha dbo come schema di default) ricostruiamo lo scenario che mi si è presentato.

Creo lo schema non di default per l'utente, chiamandolo MioSchema

-- creo lo schema
CREATE SCHEMA MioSchema
---------------------------------------------------------------

Successivamente creo due oggetti con lo stesso nome:

-- creo due tabelle con lo stesso nome, ma con schema diverso
---------------------------------------------------------------
CREATE TABLE dbo.Eventi
(
      IDEvento int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
      Evento varchar(100)
)

CREATE TABLE MioSchema.Eventi
(
      IDEvento int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
      Evento varchar(100)
)

INSERT dbo.Eventi (Evento) VALUES ('Gran premio di formula 1')
INSERT dbo.Eventi (Evento) VALUES ('ATP Tour golf')
INSERT dbo.Eventi (Evento) VALUES ('Tennis Master Series')
INSERT dbo.Eventi (Evento) VALUES ('Campionato di Sci')
INSERT dbo.Eventi (Evento) VALUES ('Mondiali di nuoto')

INSERT MioSchema.Eventi (Evento) VALUES ('SERIE A Tim')
INSERT MioSchema.Eventi (Evento) VALUES ('Premier League')
INSERT MioSchema.Eventi (Evento) VALUES ('Liga')
INSERT MioSchema.Eventi (Evento) VALUES ('Bundesliga')
INSERT MioSchema.Eventi (Evento) VALUES ('Ligue')

---------------------------------------------------------------

Ora, lanciando una selezione dell'intera tabella omettendo lo schema otterremo il seguente risultato:

SELECT * FROM Eventi

Questo è il risultato che ci si aspettava, poichè il primo oggetto ad essere letto è quello identificato da dbo.Eventi poichè dbo è il default schema.
Rilanciando la stessa query, utilizzando un utente che ha come default schema MioSchema (creato all'inizio), il risultato sarà:



Fino a qui tutto ok. Ma ora passiamo a quello che mi ha decisamente ingannato.
Creiamo la seguente stored procedure:

CREATE PROCEDURE MioSchema.proc_Eventi
AS
      SET NOCOUNT ON;

      SELECT * FROM Eventi
GO

Che ci si aspetta? Dati dalla tabella su dbo? dalla tabella di MioSchema?
Erroneamente, e ci sono proprio cascato, mi aspettavo dati da dbo. Ma non è così. I BOL lo evidenziano con la seguente frase passatami da Lorenzo:
"Inside a stored procedure, object names used with statements (for example, SELECT or INSERT) that are not schema-qualified default to the schema of the stored procedure."
In poche parole.. i dati tornati dalla stored procedure in esame sono proprio quelli della tabella MioSchema.Eventi. Questo a prescindere dal default schema del mio utente. Gli oggetti indicati senza schema nella stored proc vengono considerati come oggetti dipendenti dallo stesso schema della stored, in casi di ambiguità.



Nella sitauzione reale, questo problema si è verificato dopo il porting di un database SQL Server 2000 verso la versione 2005. Il mio collega Marco ha aggiunto uno schema per aggiungere nuovi oggetti e non appena si è trovato questa situazione di ambiguità (due viste con lo stesso nome ma diverso schema), si è subito reso conto che qualcosa non andava. I dati che si è trovato di fronte non erano quelli che si aspettava.
La prima operazione eseguita per capire dove stesse il problema (sinceramente non ci abbiamo pensato subito) è stata quella di copia-incollare il contenuto della stored procedure in una nuova query per poi eseguirla al di fuori dello scope della procedura. Il tutto funzionava come ci si aspettava.
Dopo i primi tentativi, siamo arrivati alla conclusione che il problema stesse proprio nello schema sotto cui è salvata la stored proc. E grazie alla frase nei BOL, abbiamo capito definitivamente il problema, anche se a questo punto non lo era più effettivamente
Questo esempio dovrebbe far capire quanto è importante seguire alcune regole molto importanti:
- leggere bene i BOL
- usare SEMPRE la naming NomeSchema.NomeTabella per evitare problemi legati all'ambiguità
- conseguentemente alla precedente regola, indicare anche lo schema dbo che alcuni sicuramente omettono ancora abituati a non utilizzarlo spesso sulla versione 2000.

Personalmente utilizzo sempre la naming NomeSchema.NomeTabella ma questo porting mi ha decisamente "fregato"

Ho deciso di postare questo caso, perchè alcuni di questi errori possono portare a considerazioni errate. Non è da tutti i giorni trovarsi una stored procedure che non torna i dati attesi ed il cui contenuto, con gli stessi parametri, fa quello che deve fare. Si tratta di quelle cose a cui subito, magari, non si pensa.. ma che è sempre bene tenere a mente. Certo è che, seguendo la naming convention, nulla di tutto ciò sarebbe accaduto. Un codice scritto chiaro vince sempre!

Stay tuned!