Wenn wir die gespeicherte Prozedur von SQL Server in ASP aufrufen und das Adodb.Command-Objekt verwenden, verwenden wir normalerweise den folgenden Code:
dim cmd, rs
set cmd = Server.CreateObject("ADODB.Command")
cmd.ActiveConnection = Verbindung
cmd.CommandType = adCmdStoredProc
cmd.CommandText = "TestProc"
cmd.Parameters.Append cmd.CreateParameter("@a", adInteger, adParamInput, 4, 1)
cmd.Parameters.Append cmd.CreateParameter("@b", adVarChar, adParamInput, 50, 'b')
...
set rs = cmd.Execute
Als ich heute ein Programm debuggte, stellte ich fest, dass auf der ASP-Seite angegeben wurde, dass einem bestimmten Parameter kein Wert zugewiesen wurde, es sich jedoch tatsächlich um einen anderen Parameter handelte, dem ich keinen Wert zugewiesen hatte. Also habe ich den Profiler von SQL Server geöffnet, das Programm ausgeführt und festgestellt, dass die von ASP an SQL Server gesendete SQL-Anweisung tatsächlich die folgende Form hatte:
TestProc 1 ausführen, 'b', ....
Der Grund ist jetzt offensichtlich. Die ADO-Engine übersetzt den Aufruf der gespeicherten Prozedur jedoch nicht in eine vollständige Syntax, sondern verwendet die oben genannte Abkürzungsmethode. Auf diese Weise kann es passieren, dass ein Parameter in der Mitte verloren geht, weil er aufgrund eines anderen Parameters verloren geht Fehlausrichtung.
Dann habe ich die Eigenschaften des Command-Objekts überprüft und den folgenden Satz hinzugefügt:
cmd.NamedParameters = true
, was bedeutet, dass ich die Verwendung einer explizit benannten Variablenform angibt. Dann habe ich das Programm ausgeführt und festgestellt, dass die Anweisung im Ereignisprofiler erfasst wurde Nun:
exec TestProc @a = 1, @b = 'b', ...
die Fehlerparameter sind auch korrekt.
Jetzt ist alles in Ordnung