Come posso evitare di troncare silenziosamente gli input della stored procedure?

Question

Utilizziamo le classi standard System.Data, DbConnection e DbCommand, per connettersi a SQL Server da C# e abbiamo molte stored procedure che richiedono i parametri VARCHAR o NVARCHAR come input. Abbiamo riscontrato che né SQL Server né la nostra applicazione C# generano alcun tipo di errore o avviso quando una stringa più lunga della lunghezza massima di un parametro viene passata come valore a tale parametro. Invece, il valore viene silenziosamente troncato alla lunghezza massima del parametro.

Così, per esempio, se l'ingresso stored procedure è di tipo VARCHAR(10) e passiamo nel 'U R PRETTY STUPID', stored procedure riceve l'input come 'U R PRETTY', che è molto bello, ma assolutamente non quello che volevamo dire da dire.

Quello che ho fatto in passato per rilevare questi troncamenti e che cosa others have likewise suggested, è di rendere la lunghezza di input del parametro un carattere più grande del necessario e quindi verificare se la lunghezza dell'input è uguale a quella nuova lunghezza massima . Quindi nell'esempio sopra il mio input diventerebbe VARCHAR(11) e vorrei verificare l'input di lunghezza 11. Qualsiasi input di lunghezza 11 o più sarebbe catturato da questo controllo. Funziona, ma si sente sbagliato. Idealmente, il livello di accesso ai dati rileverà automaticamente questi problemi.

C'è un modo migliore per rilevare che l'input della stored procedure fornito è più lungo di quello consentito? DbCommand non dovrebbe essere già a conoscenza dei limiti di lunghezza in ingresso?

Inoltre, per curiosità, cosa è responsabile per troncare silenziosamente i nostri input?

Answer 1

Utilizzare VARCHAR(8000), NVARCHAR(4000) o anche N/VARCHAR(MAX), per tutte le variabili e i parametri. In questo modo non devi preoccuparti del troncamento quando assegni @variables e @parameters. Il troncamento maggio si verificherà durante l'effettiva scrittura dei dati (inserimento o aggiornamento) ma non è silenzioso, provocherà un errore grave e lo scoprirai. È inoltre possibile ottenere il vantaggio aggiuntivo del codice di procedura memorizzato che non deve essere modificato con le modifiche dello schema (modificare la lunghezza della colonna, il codice è ancora valido). Inoltre, è possibile ottenere un comportamento migliore della cache del piano utilizzando lunghezze dei parametri coerenti, vedere How Data Access Code Affects Database Performance.

Tenere presente che si verifica un leggero calo di prestazioni per l'utilizzo dei tipi MAX per i parametri @ variables/@, vedere Performance comparison of varchar(max) vs. varchar(N).