TADOCommand mit Parametern - PK-Verletzung

[Peinhard]

Params[i]...? Oder meintest du Parameters[i]? Und hast du mal mit property ParamCheck gespielt?

[Furtbichler]

Wenn Du die Tabellen kennst, und weißt, für welche Spalten Du Parameter verwendest, dann kannst Du dein Skript so zusammenbauen, das der Datentyp korrekt wiedergegeben wird.

Beim Skript kannst Du dir vielleicht mit dem Datentyp SQL_VARIANT behelfen.

Auf jeden Fall sollte den Parametern der jeweils richtige Datentyp zugewiesen werden.

Beim dynamischen Zusammenbasteln von Skripten verwende ich keine Parameter, sondern eigene Formatierungsroutinen, die natürlich das Injection-Problem behandeln.

Dessenungeachtet würde ich mir überlegen, die Transaktion vom TADOConnection-Objekt erledigen zu lassen. Erzeuge einfach eine Exception (RAISEERROR), wenn Du in deinem Skript das Rollback forcieren willst.

[sx2008]

Es wurde ja schon gesagt, dass man jeden Parameter nur einmal benützen darf.
Aber zusätzlich ergibt sich noch folgendes Problem:
Die VCL versucht den CommandText zur Entwicklungszeit zu parsen um die Datentypen und Datenrichtung der Parameter zu ermitteln.
Bei einfachen oder "normalen" SQL-Abfragen klappt das auch recht gut.

Delphi-Quellcode:

// Beispiel
CommandText := 'SELECT * FROM Tabelle WHERE Status=:Param1';

Die VCL öffnet die Datenbank im Hintergrund und fragt die Felder der Tabelle ab.
Der Parameter Param1 bekommt dann den Datentyp (ggf. auch Länge oder Anz. Nachkommstellen) des Feldes Status verpasst.
Ausserdem erkennt der Parser, dass es sich um einen Input-Parameter handelt.

Bei SQL-Anweisungen mit mehr als einem Befehl (getrennt durch Strichpunkt) funktioniert der Parser nicht mehr so richtig.
Der Parser erkennt noch die Namen der Parameter aber der Datentyp ist Unknown.
Und deshalb funktioniert dann auch die Wertübergabe der Parameter nicht.

Eine Stored Proc, wie von NormanG vorgeschlagen, würde dem Parser wieder ermöglichen die Datentypen & Richtungen zu ermitteln.

Man kann aber auch die ADODataset-Komponenten schon zur Entwicklungszeit erstellen und mit dem Objektinspektor die Datentypen der Parameter festlegen.
Oder man legt die Datentypen später per Code fest.
Auf jeden Fall bewegt man sich in schwierigem Gelände wenn man ganze SQL-Scripts per Parameter versorgen möchte.

[Jumpy]

Kann man das denn nicht mit mehreren Querys hintereinander erledigen, so nach dem Motto:

if exists then update else insert;

wobei exists schaut, ob's den PK schon gibt ('Select count(*) where PK = :MyPK'), und update und insert halt entsprechende SQL-Statements abschicken.

[Iwo Asnet]

Zitat:

Zitat von Jumpy (Beitrag 1170576)

Kann man das denn nicht mit mehreren Querys hintereinander erledigen, so nach dem Motto

Das ist so ziemlich die langsamste Lösung, vor allen Dingen mit 'SELECT COUNT(*)'.
Das mit dem Skript ist schon ein guter Ansatz. Wenn er Fragesteller das dynamisch für beliebige Tabellen machen will, kommt man aber mit dem SP-Ansatz nicht weiter, hier hilft dann wirklich nur ein ordentlich zusammengebautes Skript, eben mit Angabe des Datentyps.

[hyype]

auch wenn ich den datentyp explizit setze, ftInteger oder ftWord, funktioniert es nicht
der parser setzt den parameter offenbar nicht ein, beim convert(int,:wid) erhalte ich eine -1
denkt ihr, dass ich es irgendwie so umbauen kann , dass es funktioniert,
oder muss ich mich von meiner variante verabschieden und es tatsächlich auf mehrere statements aufteilen?

[hyype]

Es ist nicht das Convert(int,...), was die -1 produziert,
im Profiler habe ich gesehen, dass der Parameter WID (heißt dann dort @P1) den Wert -1 hat,
damit ist mein Parameter @ID -1 und da ich den dann einsetze, wird -1 weggeschrieben...

[hyype]

ich habe es geschafft!!!

und ihr werdet nicht glauben, woran es im Endeffekt lag...
und ihr hattet im Grunde keine Chance, mich darauf zu bringen, weil ich euch mit unzureichenden Informationen gefüttert habe... :/

Ich habe immer AC.execute(iRecordsAffected) aufgerufen, wobei AC ein TADOCommand und iRecordsAffected ein integer ist.
Ich habe das jetzt mal umgestellt auf AC.execute(iRecordsAffected, EmptyParam), eigentlich blos, um die Anzahl der veränderten Zeilen zurück zu bekommen,
um damit dann ein update hinzuschicken und wenn 0 zurück kommt dann das insert, aber das ist jetzt nicht mehr nötig, denn mein statement funktioniert!!!

Vielen Dank an alle Beteiligten!

mfg

hyype