Ogni tanto mi stupisco dei titoli ignoranti che riesco a forgiare...
In ogni caso, volevo solo ricordare con un breve appunto il rischio che si corre rinominando gli oggetti del db direttamente dall'object explorer di Management Studio.
Supponiamo di avere la nostra stored procedure, award winning per fantasia, dbo.stp_test.
Per accedere alla sua definizione ci basta utilizzare, avendo i permessi di farlo, la funzione di sistema OBJECT_DEFINITION:
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.stp_test')) AS ObjectDef
Altre due alternative per ottenere la definizione di un oggetto sono la SP sp_helptext e la VIEW sys.sql_modules.
Eseguendo la query otteniamo il seguente risultato, che è il testo dello script utilizzato per creare l'SP:
Ora, in un lampo di normalità, ci accorgiamo che il nome di questa stp non è del tutto chiaro e decidiamo di cambiarlo in qualcosa di più utile e comprensibile, ma per farlo utilizziamo direttamente l'object explorer di Management Studio:
Se ora rieseguiamo la query di poco fa, opportunamente modificata
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.stp_testuggine')) AS ObjectDef
otteniamo, con sommo gaudio, ancora il medesimo risultato di prima:
La definizione del nostro oggetto, se il suo nome viene modificato dal TreeView di SSMS, rimane immutata. Se dovessimo aver fatto un rename da interfaccia, tuttavia, basta andare in modifica della SP e rieseguirla anche senza effettuare alcun cambiamento in essa. L'operazione di ALTER PROCEDURE fa sì che la definizione della nostra SP venga aggiornata correttamente.
Per ovviare a questo incoveniente, dovendo rinominare, ad esempio, una SP come in questo caso, la scelta migliore sarebbe quella di eseguire un DROP dell'oggetto seguito da un CREATE dello stesso, operazione che SSMS 2008 propone direttamente da menu contestuale (non ricordo in questo momento se anche il 2005 ha questa voce di menu - Igor mi conferma che nel 2005 non era presente, grazie!):
Una nota, in chiusura.
Nella maggior parte dei casi questo disallineamento non causa problemi, ed è del tutto trasparente all'operatività normale. Il nome dell'oggetto viene correttamente aggiornato, e l'esecuzione della SP, utilizzando il nome nuovo, riesce senza alcun tipo di problema. Alla prima modifica tutto si riallinea e non ci si accorge di nulla.
Alcuni problemi, invece, possono insorgere in particolari casi in cui un qualche tipo di procedura accede direttamente a questa definizione. Un caso concreto che mi sono trovato davanti è stato quello di una nostra applicazione .NET che tramite una SP recuperava un'elenco delle definizioni degli oggetti, ne calcolava l'albero delle dipendenze (tramite la VIEW sys.sql_dependencies - ormai obsoleta, sostituita da sys.sql_expression_dependencies) e creava uno script di pubblicazione. In SQL 2005 infatti, su DB con una grossa mole di oggetti, il tempo di generazione script era paurosamente elevato se paragonato a quello di SQL 2000, ed avevamo optato per una soluzione fatta in casa che in pochi secondi creasse tale script. Seppure fosse prassi il DROP&CREATE per rinominare gli oggetti ove necessario, un paio di SP erano state rinominate da Object Explorer e ovviamente, quando lo script le aveva ricreate sul DB di destinazione, i nomi delle due SP erano rimasti quelli vecchi e non quelli nuovi, creando un disallineamento ed un fastidioso bug. Scoperto il problema, avevamo provveduto, per ogni evenienza, a creare una SP di verifica che ci elencasse tutti gli oggetti il cui name non fosse contenuto nella sua definition. Brutale e funzionale.
Per la cronaca: la procedura di pubblicazione è stata ormai sostituita da un più completo e funzionale SQL Compare di RedGate :D