SQL UPDATE will nicht

[Privateer3000]

[QUOTE=mkinzler;1193446]

Delphi-Quellcode:

DataSet.Edit;
DataSet.FieldByName(<Feld>).Value := <Wert>;

->
Entsprechender Wert in Parameter des UpdateSQL wird gesetzt.

Delphi-Quellcode:

DataSet.Post;

->

Delphi-Quellcode:

UpdateSQL.ExecuteSQL;

wird ausgeführt

Hallo MArkus,
ich kenne das Tut von Delphi-Treff.
Es ist nur irgendwie verwirrend.

Code:

UpdateSQL.ModifySql: UPDATE namenSET    recno = :RecNo,       name  = :nameWHERE  recno = :old_recno

Ich habe die Paras auch w.o. mit Doppelpunkt gekennzeichnet.
Die Updatekomponente hab ich auch schon im Gebrauch, nur halt ohne Paras.
Weil ich es nicht verstehe.
Wie sollte der nachstehende (funktionierende) Source richtig aussehen:

Code:

 
vquery.Edit;
  sqltext1:=TStringList.Create;
  sqltext1.Add('UPDATE tabelle SET NEU='+IntToStr(1)+' WHERE SP1='+IntToStr(salt1)+' AND SP2='+IntToStr(salt2));
  vupdate.ModifySQL:=sqltext1;
vquery.Post;

vquery : TZQuery
vupdate: TZUpdateSQL

[EgonHugeist]

@Privateer3000

Ich versuchs dir mal zu erklären, wie die Komponenten arbeiten.

Im Grundsatz stellt sie nichts weiter dar als einen Holder für drei verschieden Statements: Inser, Update, Delete.

Aufgabe der Compo ist es den anderen DataSet-Komonenten das erstellen eben dieser benötigten Statements abzunehmen. Deshalb solltest du z.B. die TZQuery.UpdateObject := TZUpdateSQL zuweisen. Die Komponente bietet einen Editor, um eben die drei Statments zusammenzubasteln. (Doppelclick auf jene.) Du kannst dort den Feldnamen einen Parameter zuweisen, wie es im Delphi-Treff beschrieben ist oder schau mal hier: http://sourceforge.net/projects/zeos...hots/95422.jpg manchmal sagt ein Bild mehr als tausend Worte.

Ebenfalls kannst du dort default-values und die Parameter-Typen hinterlegen. Mit Hilfe dieser Komponente legt Zeos den Erfolg der Statments in die Hände der Benutzer. Es gab in der Vergangenheit einfach zu viele Bugreport wegen NOT_NULL Felder oder Feldern mit default-values mit Queries, welch sich über mehrere Tables erstrecken. Benützt man nun queries mit joins, welche sich ins Unendliche Erstrecken können, verweigert Zeos mit den DataSet-Komenten jeglich Art der Updates. Siehe: http://www.delphipraxis.net/171396-m...-more-tha.html ! Einfach weil das Parsen solcher Queries nun nicht wirklich Aufgabe von Zeos ist, Geschwindigkeiten verlohren gehen und vielmehr die der Datenbank und Zeos für jeden Provider extra Anpassungen bräuchte und sich die Frage stellt: wo anfangen und wo aufhöhren.

Zurück zum Thema:

Also du hast die TZDataSet-Komponente mit der TZUpdateSQL-Kompo verknüpft und die drei nötigen Statements generiert.

Die Komponente ist jedoch NICHT für das ausführen der Statements oder zuweisen der Parameter-Values gedacht, kann es jedoch. Dies tun die TZDataSet-Komponenten für dich. Wie bekannt, kannst du in der TZQuery etc. Felder und auch Parameter zuweisen. Die Felder werden in der Regel von den Controls genutzt. Entspricht ein Feld einem zugewiesenem Parameter nutzt Zeos automatisch den Parameter um die geänderten Daten der Controls dem Parameter zuzuweisen. Jedoch kannst auch du die Parameter selber füllen. JEDOCH die Parameter der TZDataSet-Komponente und nicht die der TZUpdateSQL-Komponente.

Simples Beispiel:

ZUpdateSQL1.ModifySQL := 'update tabelle1 set tabelle1.Feld1 = :Feld1; //funktioniert auch! Feld1 sollte aber im selct der TZQuery entahlten sein.
ZQuery1.UpdateObject := ZUpdateSQL1;
ZQuery1.Edit;
ZQuery1.ParamByName('Feld1'').AsString := 'Test';
ZQuery1.Post;

Ich hoffe dies war etwas verständlicher.

Gruß Michael

[Privateer3000]

Vielen Dank Michael,
für deine Erklärungen.
Langsam kommt Licht ins Helle :)
Denn an sich scheint das eine durchaus komfortable Sache zu sein.
Dass der Feldname als Paramter fungiert erschloss sich mir garnicht.
Ich kannte bisher nur im SQL-String übergebene Parameter die angesprochen
werden können.
Diese ZEOS (ehem. BDE?) Komponenten sind halt noch neu für mich
das ich bisher nur mit ADO handtiert hatte.

Vielen Dank nochmals
Grüße

[EgonHugeist]

Kein Problem. Leider fehlt mir die Zeit überall eine "sinnvolle" Antwort zu geben, da ich eigentlich nur auf der Suche nach noch offenen Problemen für das Zeos7 Stable-Release 7.0.2 zu Weihnachten/Neujahr bin.

Ob Zeos jehmals irgendwas mit der BDE zu tun hatte kann ich dir auch nicht sagen, wage dieses jedoch zu bezweifeln. Ich nutze Zeos erst das zweite Jahr aktiv und seit fast einem Jahr hab ich da mal angefangen alles wieder auf den neuesten Stand der Dinge zu bringen. Ich denke vielmehr das Zeos ehemals eine Pascal-Protierung der JDBC Klassen gewesen ist und sich dann einfach in eine eigene Richtung entwickelt hat.

Vieleicht würde anderen die vorherige kurze Erklärung auch helfen? Im LCL-Forum mein ich?

Schau ich selber kannte auch die gesamten Möglichkeiten vorher nicht. Jedoch im Zuge der ehrenamtlichen Arbeit am Projekt entdeckt man immer wieder Dinge und Möglichkeiten, welche man stehenden Fußes und mangels Dokumentation kaum ersehen kann. Und Zeos ist mittleweile wieder ein echter Mitstreiter gewurden (nach 3Jahren durchhängens), hat die FPC-SQLDB Komponenten wieder weit abgeschüttelt und steht gegen comerziell hochpreisige Produkte auch nicht wirklich schlecht da, denke ich jedenfalls. Dennoch sollten wir realistisch bleiben, daß eine vollständig Bug-freie und 100% Dokumentierte Version wohl nie möglich sein wird, solange nicht einmal eine Hand voll Leute daran mitarbeiten und nur Fehler behoben werden können, welch nachvollziehbar sind.

Falls Interesse besteht, Zeos7.1.0-alpha ist schon in Arbeit. Sollten irgenwelche Probleme auftauchen, sei so gut und melde dich im Zeos-Forum.

Ich hoffe du kommst nun mit der Komponente und deiner Arbeit zurecht. Oft erschließt sich alles ein wenig klarer, wenn der erste Schritt getan wurde. Und ja das Arbeiten mit der Komponente ist eine tolle Sache und garantiert ein Fehler-freie Arbeit, wenn man erst einmal verstanden hat, wie das Dingenskirchen rockt. :cyclops:

PS: versuche ADO zu vermeiden, da beim Wrappen/anpassen zu ODBC dann zu OLEDB und vice versa 'ne Menge Performance liegen bleibt. Nativer zugriff ist immernoch das schnellste.

[Privateer3000]

Zitat:

Zitat von EgonHugeist (Beitrag 1193629)

PS: versuche ADO zu vermeiden, da beim Wrappen/anpassen zu ODBC dann zu OLEDB und vice versa 'ne Menge Performance liegen bleibt. Nativer zugriff ist immernoch das schnellste.

Das war auch ein Grund warum ich mich von ADO verabschieded hatte, sowie die Multiuser Problematik.
Nebenher muss ich mit Filemaker arbeiten, was zugegebenermaßen ganz lustig ist.

Vielen Dank Michael für deine ausführliche Antwort. Es tauchen immer neue Fragen auf je mehr man sich damit Beschäftigt.
zB TZStoredProc und TZQuery. Was ist der tatsächliche Unterschied? Beide geben Ergebnismengen zurück und führen Inserts aus.
Bis auf ein unnötiges Prepare, sehe ich keinen Unterschied.

Das ZEOS nichts nativ mit BDE zu tun hat, ist mir bekannt. Es ging mir um parallele Eigenschaften mit BDE.
Ich hab mal ne Zeit mit BDE gearbeitet, ich fands zum Haareraufen.

Sollte ich irgendwann Fehler entdecken, die nicht meiner Unfähigkeit entspringen :) werde ich das im ZEOS Forum posten.
Aber bis dahin wird noch einiges an Wasser den Niagara herunterplätschern.
Grüße

[p80286]

Zitat:

Zitat von EgonHugeist (Beitrag 1193629)

PS: versuche ADO zu vermeiden, da beim Wrappen/anpassen zu ODBC dann zu OLEDB und vice versa 'ne Menge Performance liegen bleibt. Nativer zugriff ist immernoch das schnellste.

Da muß ich leider widersprechen. Dank genialer Treiber und meiner eigenen Genialität, nicht zu vergessen einiger ebenso genialer Tips aus diesem Forum, ist es mir gelungen, DB-Zugriffe zu realisieren, die originären Zugriffen nicht nachstehen.

Zumindestens das Oracle-Original ist nicht besser.

Aber wie oben schon zart angedeutet, das liegt nur an meiner Genialität.

Gruß
K-H

[EgonHugeist]

@privateer3000

Neue Frage, neuer Thread.
Kurze Andeutung: Ja es gibt da Unterschiede, obwohl TZStoredProc ein TZDataSet descendant ist. Ob du jene Unterschiede mit FireBird ermessen kannst, glaub ich nicht. Jedoch sieht's da bei anderen Anbietern schon ganz anders aus.

[Privateer3000]

Zitat:

Zitat von EgonHugeist (Beitrag 1193499)

@Privateer3000

Simples Beispiel:

ZUpdateSQL1.ModifySQL := 'update tabelle1 set tabelle1.Feld1 = :Feld1; //funktioniert auch! Feld1 sollte aber im selct der TZQuery entahlten sein.
ZQuery1.UpdateObject := ZUpdateSQL1;
ZQuery1.Edit;
ZQuery1.ParamByName('Feld1'').AsString := 'Test';
ZQuery1.Post;

Ich hoffe dies war etwas verständlicher.

Gruß Michael

Ich nehm das nochmal auf:
bedeutet das, die where Klausel wird von dem Query übernommen?!
denn ich muss ja die Zeile festelegen können wo das Update gemacht wird...

[EgonHugeist]

Sorry, ging nicht aus meinem quick and dirty code vor.

Nein für die where clausel mußt du selbstverständlich auch sorgen, da die drei update Statements unabhängig sind.

Das sollte sich beim öffnen des Editors eigentlich auch von selbst ergeben (hoffe ich).

Gruß Michael

[Privateer3000]

Zitat:

Zitat von EgonHugeist (Beitrag 1193950)

Das sollte sich beim öffnen des Editors eigentlich auch von selbst ergeben (hoffe ich).

Gruß Michael

äh, nö :)