7 Stimmen

Delphi: "Das Parameterobjekt ist nicht korrekt definiert. Es wurden inkonsistente oder unvollständige Informationen bereitgestellt."

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

Ich habe nach diesem Fehler gegoogelt und immer das gleiche Ergebnis gefunden: Er kommt daher, dass Sie irgendwo in Ihrer Abfrage einen Doppelpunkt in einer Zeichenfolge haben, was den SQL-Parser von ADO stört. Dies ist hier nicht der Fall. Es gibt nirgendwo falsche Doppelpunkte. Ich habe die Objektdefinition mit dem Schema der Tabelle, in die ich etwas einfügen möchte, abgeglichen und überprüft. Alles ist in Ordnung, und meine Kollegen sind ratlos. Weiß jemand, was sonst noch die Ursache sein könnte? Ich bin hier mit meinem Latein am Ende.

Ich verwende Delphi 2007 und SQL Server 2005.

0 Stimmen

@Mason - Verwenden Sie Parameter? Wenn nicht, hilft es, ParamCheck := False zu setzen?

4voto

Ich kann diesen Fehler bekommen, mit Delphi 2007 und MSSQL Server 2008, und ich fand einen Workaround. (die ziemlich beschissen IMHO ist, aber vielleicht seine nützlich für Sie, wenn Ihre 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;

Ich habe zwei Möglichkeiten gefunden, das Problem zu lösen:

1) Entfernen Sie die Klammern aus der SQL, d.h.:

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

2) zwei Parameter anstelle von einem zu verwenden:

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;

3voto

kPkPkP Punkte 31

Ich habe diesen Thread bei der Suche nach der oben erwähnten Ausnahmemeldung gefunden. In meinem Fall war die Ursache ein Versuch, einen SQL-Kommentar /* foo */ in meinen query.sql.text einzubetten.

(Ich dachte, es wäre praktisch gewesen, einen Kommentar in meinem Profiler-Fenster vorbeiziehen zu sehen).

Wie auch immer - Delphi7 hat das gehasst.

0 Stimmen

Das Gleiche gilt für mich, in Delphi 2010. Ich habe allerdings einen "-- foo"-Kommentar hinzugefügt.

2voto

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

Ich habe versucht, der Datenbank eine gespeicherte Prozedur 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';

Als ich den Doppelpunkt (:) entfernte, funktionierte es. Denn es sah den Doppelpunkt als Parameter.

1voto

RBA Punkte 12005

Ich habe den gleichen Fehler wie in Ihrer Frage beschrieben. Ich habe den Fehler auf folgende Punkte zurückgeführt ADODB.pas -> procedure TParameters.AppendParameters; ParameterCollection.Append(Items[I].ParameterObject) .

Durch die Verwendung von Haltepunkten wurde der Fehler in meinem Fall durch einen Parameter ausgelöst, der ein DateTime Feld in der Datenbank und ich habe den Parameter nie ausgefüllt. Das Einrichten des parameter().value:='' hat das Problem gelöst (ich habe es auch mit varNull aber es gibt ein Problem - anstatt Null in der Datenbank zu senden, sendet die Abfrage 1 - den ganzzahligen Wert von varNull ).

PS: Ich weiß, das ist eine "späte späte" Antwort, aber vielleicht kommt jemand auf den gleichen Fehler.

0 Stimmen

Ich hatte ein ähnliches Problem, aber ich habe es geschafft, NULL zu senden (siehe meine Antwort)

0 Stimmen

Ich habe gerade das gleiche Problem, das manchmal auftritt, manchmal nicht, und ich habe es auch geschafft, es auf TParameters.AppendParameters zurückzuführen. Ich habe festgestellt, dass dem Parameter, der das Problem verursacht, der Wert NULL zugewiesen wurde. Das Ändern des Wertes in Unassigned scheint das Problem behoben zu haben. Aber was mich wirklich stört, ist die Tatsache, dass der Fehler nur manchmal auftritt.

0 Stimmen

" Ich habe es auch versucht mit varNull aber es gibt ein Problem - anstatt Null in der Datenbank zu senden, sendet die Abfrage 1 - den ganzzahligen Wert von varNull " - Sie erstellen keine NULL Variant durch wörtliche Zuweisung von varNull selbst zum Variant . Sie müssen die TVarData(Variant).VType Feld zu varNull stattdessen. Sie können dies manuell tun, oder Sie können einfach das Ergebnis der Variants.Null() Funktion zum Variant stattdessen.

1voto

FreeText Punkte 199

Ich bin gerade selbst 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 einwandfrei, schlägt aber in Delphi über das TAdoQuery-Objekt fehl. Mein Fehler kam von einem Doppelpunkt (Entschuldigung an den ursprünglichen Poster) von einem Datum/Zeit-Wert.

Soweit ich weiß, ist das Datums-/Zeitformat von Jet SQL #mm/dd/yyyy hh:nn:ss# (0 Links-Padding ist nicht erforderlich).

Wenn die Eigenschaft TAdoQuery.ParamCheck True ist, schlägt dieses Format fehl. (Danke an die Poster!) Zwei Abhilfen sind: a) ParamCheck auf False setzen oder b) ein anderes Datums-/Zeitformat verwenden, nämlich "mm/dd/yyyy hh:nn:ss" (MIT den Anführungszeichen).

Ich habe beide Optionen getestet, und sie haben beide funktioniert.

Auch wenn es sich bei dem Format mit den doppelten Anführungszeichen nicht um das Jet-Datums-/Zeitformat handelt, ist Access bei diesen Datums-/Zeitformaten ziemlich flexibel. Ich vermute auch, dass es etwas mit dem Datums-/Zeitformat von BDE/LocalSQL/Paradox (Delphi 7's native SQL- und Datenbank-Engine) zu tun hat (verwendet doppelte Anführungszeichen, wie oben). Der Parser ist wahrscheinlich so konzipiert, dass er Zeichenketten in Anführungszeichen ignoriert (doppelte Anführungszeichen sind das Trennzeichen für Zeichenketten in BDE LocalSQL), kann aber bei anderen, nicht nativen Datums-/Zeitformaten ins Straucheln geraten.

SQL Server verwendet einfache Anführungszeichen zur Begrenzung von Zeichenketten, so dass dies beim Schreiben in SQL Server-Tabellen anstelle von doppelten Anführungszeichen funktionieren könnte (nicht getestet). Oder vielleicht stolpert das Delphi TAdoQuery Objekt immer noch. Das Ausschalten von ParamCheck könnte in diesem Fall die einzige Option sein. Wenn Sie vorhaben, den Wert der ParamCheck-Eigenschaft im Code umzuschalten, können Sie etwas Verarbeitungszeit sparen, indem Sie sicherstellen, dass die SQL-Eigenschaft leer ist, bevor Sie sie aktivieren, wenn Sie nicht vorhaben, die aktuelle SQL zu analysieren.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X