Come posso controllare a livello di codice (analizzare) la validità di un'istruzione TSQL?

Question

Sto cercando di rendere i miei test di integrazione più identi- cienti. Un'idea era quella di eseguire il rollback dopo ogni test, l'altra idea era quella di analizzare in modo analitico il testo, in modo simile alla casella di controllo verde in Query Analyzer o SSMS.

Come si ottiene SQL Server per analizzare il mio comando senza eseguirlo tramite ADO.NET?

UPDATE: Questo è quello che alla fine ha funzionato, se lo desideri:

using (DbCommand executeOnly = Factory.DbCommand()) 
{ 
    executeOnly.Connection = command.Connection; 
    executeOnly.CommandType = CommandType.Text; 
    executeOnly.CommandText = "SET NOEXEC ON;" + sqlCommand; 
    executeOnly.Connection.Open(); 
    executeOnly.ExecuteNonQuery(); 
} 
//set more properties of command. 
command.Execute(); 

Per motivi inspiegabili, "SET PARSEONLY ON" ha lavorato solo in Query Analyzer. Non ho potuto impostare questo su una connessione ADO.NET. Lo è anche perché PARSEONLY sembra catturare solo gli errori di sintassi, che non è un errore comune. SET NOEXEC ON individuerà una varietà più ampia di errori, ad esempio una vista che fa riferimento a una tabella o colonna mancante oa un parametro mancante in una stored procedure.

Answer 1

Penso che il comando che stai cercando sia SET NOEXEC ON. Se si imposta questo per la connessione, le query verranno analizzate ma non verranno eseguite. Un'altra opzione sarebbe SET PARSEONLY ON, ma onestamente non sono sicuro di quale sia la differenza tra i due.

Answer 2

SET PARSEONLY: Esamina la sintassi di ogni istruzione Transact-SQL e restituisce eventuali messaggi di errore senza compilare o eseguire l'istruzione.

Answer 3

utilizzare la seguente query

SET PARSEONLY ON 
--Your query here 
SET PARSEONLY OFF 

Answer 4

+1 alla risposta di Eric. Ma ho trovato SET FMTONLY ON anche essere utile come SET NOEXEC ON non sembra gettare tutti gli errori.

ad es.

SELECT * FROM ATableThatDoesNotExist 

esecuzione che con SET NOEXEC ON dice che era successo, nonostante la tabella non esistente nel database. Eseguendolo invece con SET FMTONLY ON, verrà generato l'errore "Nome oggetto non valido".

SET FMTONLY ON restituisce anche i metadati relativi al gruppo di risultati che sarebbe tornato, che può venire molto utile

Answer 5

Davvero Dipende lo scopo dei test.

Il modo più affidabile sarebbe quello di utilizzare il rollback dopo ogni test se le vostre affermazioni si prestano a quello (non sono troppo pesanti per renderlo praticabile).

Ho fatto questo in passato e sono stato contento di essere informato dei problemi di runtime che non avrei catturato in nessun altro modo.

Answer 6

VSTSDBPro ha un parser di query è possibile accedere a livello di codice: http://blogs.msdn.com/b/gertd/archive/2008/08/21/getting-to-the-crown-jewels.aspx

Answer 7

SQL Server 2012 possibile analizzare la sintassi, le procedure e le tabelle con le seguenti procedure e funzioni di sistema:

• sp_describe_first_result_set (Transact-SQL)
• sp_describe_undeclared_parameters (Transact-SQL)
• sys.dm_exec_describe_first_result_set (Transact-SQL)
• sys.dm_exec_describe_first_result_set_for_object (Transact-SQL)

They are supposedly replacing "SET FMTONLY".

li ho testati e funzionano molto meglio di "SET NOEXEC ON" e "SET PARSEONLY ON"

Esempi:

non viene generato un errore :

Invia correttamente un errore ("SET NOEXEC" e "SET PARSEONLY" non genera un errore in questo caso):

sp_describe_undeclared_parameters 
    @tsql = N'SELECT object_id, name, type_desc FROM sys.indexes;SELECT object_id, name, type_desc FROM sys.NOTaTABLE;'