Questa mattina mi chiedono di implementare su un sito di un cliente un sistema molto semplice di scontistica applicato all'input di un codice promozionale.
Niente di più semplice dico io.
Scrivo la mia bella store procedure per verificare la correttezza del codice digitato:
CREATE PROCEDURE
dbo.uspCheckBuonoAcquisto
@CS nvarchar(6),
@Esito nvarchar(6) output
AS
IF EXISTS(SELECT field FROM Table WHERE field = @CS)
SET @Esito = 1
ELSE
SET @Esito = 0
RETURN
Poi passo a modifica la classe che gestisce l'ordine inserendo intanto una funzioncina per la validazione del codice:
Public
Shared Function CheckBuonoAcquisto(ByVal strCodice As String) As Boolean
Dim ParamList(1) As SqlParameter
ParamList(0) = New SqlParameter("@CS", SqlDbType.NVarChar, 6)
ParamList(0).Value = strCodice
ParamList(1) = New SqlParameter("@Esito", SqlDbType.NVarChar, 6)
ParamList(1).Direction = ParameterDirection.Output
SqlHelper.ExecuteNonQuery(ConfigurationSettings.AppSettings("cs"), CommandType.StoredProcedure, "uspCheckBuonoAcquisto", ParamList)
If ParamList(1).Value = 0 Then
Return False
Else
Return True
End If
End Function
Con mio assoluto sconcerto mi accorgo che il parametro ParamList(1) è praticamente sempre null, qualuque cosa succeda nella store procedure.
Dopo aver rotto l'anima a destra e a manca, trovo un bel post in un forum che spiega una cosa bellissima; praticamente richiamando il metodo ExecuteNonQuery nel modo più semplice, che è quello che uso normalmente SqlHelper.ExecuteNonQuery(sqlConnectionObjectGoesHere, "StoredProcedureNameGoesHere", parameters) tra le controindicazioni leggo: You cannot use "output" parameters or "return_value" parameter.
Rimango sconcertato...
Mi accingo quindi a modificare la funzione con la nuova sintassi: SqlHelper.ExecuteNonQuery(sqlConnectionObjectGoesHere, CommandType.StoredProcedure, "StoredProcedureNameGoesHere", parameters) e voilà il tutto funziona perfettamente.