Delphi: "Das Parameterobjekt ist falsch definiert. Inkonsistente oder unvollständige Informationen wurden bereitgestellt."

Question

Ich versuche, einen Datensatz in einer Tabelle in einem 3-Tier-Datenbank-Setup einzufügen, und der Server der mittleren Schicht generiert die obige Fehlermeldung als eine OLE-Ausnahme, wenn es versucht, den ersten Parameter der Abfrage hinzuzufügen.

Ich habe diesen Fehler gegoogelt, und ich finde das gleiche Ergebnis konsequent: Es kommt von einem Doppelpunkt in einer Zeichenfolge irgendwo in Ihrer Abfrage, die ADO SQL Parser b0rks. Dies ist hier nicht der Fall. Es gibt keine falschen Doppelpunkte. Ich habe überprüft und überprüft die Objektdefinition gegen das Schema für die Tabelle, die ich einfügen möchte. Alles schaut aus, und das hat meine Kollegen ratlos gemacht. Weiß jemand, was sonst das verursachen könnte? Ich bin hier am Ende.

Ich verwende Delphi 2007 und SQL Server 2005.

Answer 1

Wenn ich mich gut erinnere, müssen Sie explizit Put NULL-Wert auf den Parameter. Wenn Sie eine TAdoStoredProc-Komponente verwenden, sollten Sie dies in der Entwurfszeit tun.

Answer 2

Verwenden Sie Threading? Ich erinnere mich, dass ich diesen Fehler erhalten habe, als ein Timer-Ereignis eine Abfrage gestartet hat, während die ADO-Verbindung für eine andere synchrone Abfrage verwendet wurde. (Der Timer hat jede Minute ein Flag "System verfügbar" überprüft).

Answer 3

Haben Sie den DataType des Parameters festgelegt oder haben Sie ihn als ftUnknown belassen?

Answer 4

Ich kann diesen Fehler mit Delphi 2007 und MSSQL Server 2008 erhalten, und ich habe eine Problemumgehung gefunden. (. Das ist ziemlich beschissen IMHO ist, aber vielleicht ist es nützlich für Sie, wenn Ihr durch die gleiche Sache verursacht wird)

Code, um den Fehler zu erzeugen:

with TADOQuery.Create(nil) 
do try 

    Connection := ADOConnection; 

    SQL.Text := ' (SELECT * FROM Stock WHERE InvCode = :InvCode) ' 
       +' (SELECT * FROM Stock WHERE InvCode = :InvCode) '; 

    Prepared := true; 

    Parameters.ParamByName('InvCode').Value := 1; 

    Open; // <<<<< I get the "parameter object is...etc. error here. 

finally 
    Free; 
end; 

fand ich zwei Möglichkeiten, es zu beheben:

1) entfernen, die Klammern aus der SQL, dh:

SQL.Text := ' SELECT * FROM Stock WHERE InvCode = :InvCode ' 
       +' SELECT * FROM Stock WHERE InvCode = :InvCode '; 

2) zwei Parameter verwenden anstelle eines:

with TADOQuery.Create(nil) 
do try 

    Connection := ADOConnection; 

    SQL.Text := ' (SELECT * FROM Stock WHERE InvCode = :InvCode1) ' 
       +' (SELECT * FROM Stock WHERE InvCode = :InvCode2) '; 

    Prepared := true; 

    Parameters.ParamByName('InvCode1').Value := 1; 
    Parameters.ParamByName('InvCode2').Value := 1; 

    Open; // <<<<< no error now. 

finally 
    Free; 
end; 

Answer 5

Hier eine späte Antwort. In meinem Fall war es etwas ganz anderes.

Ich habe versucht, eine gespeicherte Prozedur zur Datenbank hinzuzufügen.

Query.SQL.Text := 
'create procedure [dbo].[test]' + #13#10 + 
'@param int ' + #13#10 + 
'as' + #13#10 + 
'-- For the parameter you can pick two values:' + #13#10 + 
'-- 1: Value one' + #13#10 + 
'-- 2: Value two'; 

Wenn ich den Doppelpunkt entfernt (:) es funktionierte. Da sah er den Doppelpunkt als Parameter.

Answer 6

Ich habe den gleichen Fehler in Ihrer Frage beschrieben. Ich habe den Fehler in ADODB.pas verfolgt ->procedure TParameters.AppendParameters; ParameterCollection.Append(Items[I].ParameterObject).
Durch die Verwendung von Breakppoints wurde der Fehler in meinem Fall von einem Parameter ausgelöst, der ein DateTime-Feld in der Datenbank füllen sollte, und ich habe den Parameter nie gefüllt. Einrichten des Parameters(). value: = '' löste das Problem (Ich habe auch mit varnull versucht, aber es gibt ein Problem - anstatt Null in der Datenbank zu senden, sendet Abfrage 1 - den ganzzahligen Wert von varnull).

PS: Ich weiß, es ist eine 'späte späte späte' Antwort, aber vielleicht wird jemand den gleichen Fehler erreichen.

Answer 7

Ich hatte auch das gleiche Problem, aber mit einem dynamischen Befehl (z. B. eine Update-Anweisung).
Einige der Parameter könnten NULL sein.
Die einzige Möglichkeit, wie ich es funktionierte, war die Einstellung der Parameter.DataType: = ftString und Parameter.Size: = 1 und nicht den Wert.

cmdUpdate := TADOCommand.Create(Self); 
try 
    cmdUpdate.Connection := '**Conections String**'; 
    cmdUpdate.CommandText := 'UPDATE xx SET yy = :Param1 WHERE zz = :Param2'; 
    cmdUpdate.Parameters.ParamByName('Param2').Value := WhereClause; 
    if VarIsNull(SetValue) then 
    begin 
    cmdUpdate.Parameters.ParamByName('Param1').DataType := ftString; 
    cmdUpdate.Parameters.ParamByName('Param1').Size := 1; 
    end else cmdUpdate.Parameters.ParamByName('Param1').Value := SetValue; 
    cmdUpdate.Execute; 
finally 
    cmdUpdate.Free; 
end; 

Answer 8

Ich fand diesen Thread beim Suchen der zuvor genannten Exception-Nachricht. In meinem Fall war der Grund ein Versuch, einen SQL-Kommentar/* foo */in meinen query.sql.text einzubetten.

(ich dachte, es wäre praktisch gewesen, ein Kommentar gehen, um zu sehen Vergangenheit Fenster in meinem Profiler schwimmen.)

Wie auch immer - Delphi7 dass man hasste.

Answer 9

Ich lief gerade in diesen Fehler heute auf einer TADOQuery, die ParamCheck := False hat und keine Doppelpunkte in der SQL hat.

Irgendwie Bestehen der OLECMDEXECOPT_DODEFAULT Parameter TWebBrowser.ExecWB() verursacht wurde dies für mich:

Dies zeigt das Problem:

pvaIn := EmptyParam; 
pvaOut := EmptyParam; 
TWebBrowser1.ExecWB(OLECMDID_COPY, OLECMDEXECOPT_DODEFAULT, pvaIn, pvaOut); 

Dies das Problem nicht zeigen:

pvaIn := EmptyParam; 
pvaOut := EmptyParam; 
TWebBrowser1.ExecWB(OLECMDID_COPY, OLECMDEXECOPT_DONTPROMPTUSER, pvaIn, pvaOut); 

Answer 10

Ein einzelnes Doppelzitat in der Abfrage kann auch diesen Fehler von dem, was ich gerade erlebt habe, und ich bin nicht Sie sing parameter überhaupt ...

Answer 11

Ich bin gerade auf diesen Fehler gestoßen. Ich verwende Delphi 7, um mit einer TAdoQuery-Komponente in eine 2003 MS Access-Datenbank zu schreiben. (alter Code) Meine Abfrage funktionierte direkt in MS Access, scheitert aber in Delphi durch das TAdoQuery-Objekt. Mein Fehler kam von einem Doppelpunkt (Entschuldigung für das ursprüngliche Poster) von einem Datum/Uhrzeit-Wert.

Wie ich es verstehe, Jet SQL Datum/Uhrzeit Format ist # mm/TT/JJJJ hh: nn: ss # (0 links-Padding ist nicht erforderlich).

Wenn die TAdoQuery.ParamCheck-Eigenschaft True ist, schlägt dieses Format fehl. (Danke Plakate!) Zwei Workarounds sind: a) setze ParamCheck auf False, oder b) verwende ein anderes Datums-/Zeitformat, nämlich "mm/tt/jjjj hh: nn: ss" (MIT den doppelten Anführungszeichen).

Ich testete beide Optionen und beide funktionierten.

Auch wenn dieses Datums-/Uhrzeitformat mit doppelten Anführungszeichen nicht das Jet-Datums-/Uhrzeitformat ist, ist Access ziemlich gut darin, bei diesen Datums-/Uhrzeitformaten flexibel zu sein. Ich vermute auch, dass es etwas mit dem Datum/Uhrzeit-Format von BDE/LocalSQL/Paradox (native SQL und Datenbank-Engine von Delphi 7) zu tun hat (verwendet doppelte Anführungszeichen wie oben). Der Parser ist wahrscheinlich entworfen, um in Anführungszeichen gesetzte Zeichenfolgen zu ignorieren (doppelte Anführungszeichen sind der Zeichenfolgenwertbegrenzer in BDE LocalSQL), kann aber bei anderen nicht-nativen Datums-/Zeitformaten etwas stolpern.

SQL Server verwendet einfache Anführungszeichen zum Abgrenzen von Zeichenfolgen, sodass diese beim Schreiben in SQL Server-Tabellen anstelle von Anführungszeichen verwendet werden können (nicht getestet). Oder vielleicht stolpert das Delphi TAdoQuery Objekt noch. In diesem Fall kann die Deaktivierung von ParamCheck die einzige Option sein. Wenn Sie den ParamCheck-Eigenschaftswert im Code umschalten möchten, sparen Sie Verarbeitungszeit, indem Sie sicherstellen, dass die SQL-Eigenschaft leer ist, bevor Sie sie aktivieren, wenn Sie nicht vorhaben, das aktuelle SQL zu analysieren.

Answer 12

Sie können diesen Fehler erhalten, wenn Sie versuchen, einen Zeitwert in der SQL zu verwenden, und vergessen, ihn mit QuotedStr() zu umbrechen.

Answer 13

Ich habe den gleichen Fehler. Es stellte sich heraus, dass ein Parameter der gespeicherten Prozedur als varchar (max) deklariert wurde. Habe es varchar (4000) gemacht und der Fehler ist verschwunden.