Commit geht nicht (SQL)

[harrybo]

Hi Hansa,

Du hast recht, irgendwo muss ein Post auftauchen, per Code oder über eine datensensitive Komponente (beim Wechseln des Datensatzes), denn Commit postet ja nicht automatisch. Daher ist es eine recht gängige Methode, vor dem Schließen einer Datenmenge nachzuschauen, ob der aktuelle Datensatz gerade in Arbeit ist. Ist er das, kann man posten, bzw. wie in Deinem Fall, vorher fragen:

Delphi-Quellcode:

if MessageDlg('speichern ?',mtInformation, [mbYes, mbNo], 0) = mrYes then 
  with Dataset1 do begin
    if State in [dsEdit, dsInsert] then Post;
    Transaction.Commit;
  end else 
    Transaction.Rollback;

[Hansa]

Ja, in der Richtung ist wahrscheinlich irgendwas verkehrt. Aber was ? Wo genau muß ich das edit, insert, open, close usw. aufrufen ? Die SQL-Statements enthalten ja bereits ein INSERT soll ich trotzdem noch DS.insert aufrufen ? Wenn ja wann ?

[harrybo]

Hi Hansa,

Deine Datasets haben unterschiedliche SQL-Properties fürs Selektieren, Inserten, Updaten, Löschen. Das Problem liegt wohl darin, dass Du über SelectSQL inserten willst (siehe Dein Code-Beispiel weiter oben).

Trage jeweils die SQL Statements in die Properties UpdateSQL, InsertSQL DeleteSQL des Datasets ein (geht auch über rechte Maustaste über einen bequemen Dialog, der Dir, nachdem Dur das SelectSQL definiert hast, automatisch die entsprechenden Statements einträgt). Dann sollte es klappen. Natürlich brauchst Du dann nicht mehr Dein SelectSQL umständlich zu switchen.

[Hansa]

Zitat von harrybo:

...Trage jeweils die SQL Statements in die Properties UpdateSQL, InsertSQL DeleteSQL des Datasets ein...

Wie meinst Du das genau ? Daß das SelectSQL für den Zweck hier ungeeignet ist, wurde ja bereits gesagt. Das seltsame ist aber trotzdem, wenn ich einen neuen Datensatz einfüge scheint der da zu sein. Gebe ich dasselbe wieder ein wird der update-Teil durchlaufen, siehe Quelltext. Letztenendes landet dann aber gar nichts in der DB.

Falls es eine Spezialität von FIBplus sein sollte, weil es in deren DataSet kein ExecSQL gibt: die Frage liegt bei denen auf dem Tisch. 8)

[harrybo]

Hi Hansa,

ich arbeite noch mit IBX, da Du mir leider noch nicht FIBPlus aus Deiner Sammelbestellung geliefert hast ;-). Dennoch: Dein FIBPlus Dataset hat neben SelectSQL bestimmt auch die Properties UpdateSQL, DeleteSQL, InsertSQL. Wie gesagt: Properties, das sind erstmal Strings, die ein SQL Statement enthalten. Diese Properties arbeiten nun mit den Methoden Open, Post und Delete zusammen.

Angenommen Du öffnest ein Dataset mit

Code:

Dataset1.Open;

, dann wird zum Öffnen der String verwendet, der gerade in Dataset1.SelectSQL steht.

Code:

Dataset1.Post;

schickt die Insert bzw. Update SQL-Ausführungsanweisung aus Dataset1.InsertSQL, bzw. Dataset1.UpdateSQL an die DB, in Abhängigkeit davon, welchen Status Dataset1 hat (dsInsert oder dsUpdate).

Mit Dataset1.Delete verhält es sich entsprechend.

In Deinem Fall heißt das: wenn Du gerade einen Insert Befehl in SelectSQL Deines Datasets stehen hast, dann wird beim nächsten Öffnen mit Dataset1.Open ein Datensatz eingefügt, gnadenlos, ohne Meckern seitens der DB.

Ich hoffe, das bringt etwas Licht ins Dunkel. Möglicherweise erfasse ich Dein Problem auch nicht und erzähle Dir Binsenweisheiten - dann soll's denen gewidmet sein, denen es weiterhilft.

[Lemmy]

HI Harrybo,

Hansa macht das schon richtig! Klar, die "Standardanwendung" sieht vor, dass die SelectSQL ausgefüllt wird und die INsert-/Update-/Delete-SQL von der Komponente weitestgehend selbst ausgefüllt wird.

Allerdings kann man auch in der SelectSQL ein beliebiges SQL-Statement reinschreiben und mit ExecSQL (bei IBX) ausführen.
@Hansa: Sollte das bei FIBPlus nicht gehen, dann schau dich bei den FIBPLus nach einer Komponente vrgl. mit TIBSQL um, vielleicht auch TIBQuery. Mit der Kompo kannst Du das auf alle Fälle machen...

Grüße
Lemmy

[Hansa]

Hi Lemmy,

konnte ja nur eine Frage der Zeit sein, bis ich Dich auf den Plan rufe. Ich habe zu dem Problem da gestern eine Antwort von FIBplus erhalten. Harrybo hat die schon, aber ich will sie keinem vorenthalten. Ich selber kann mich aber wohl erst heute abend intensiv damit befassen. Sieht aber auf den ersten Blick so so aus, als liefe das mit FIBplus auf eine FIBquery hinaus.

[harrybo]

Hi Lemmy, hi Hansa,

ich glaube, mir geht langsam die Puste aus, ich versuch's trotzdem nochmal: Hansa macht es nicht richtig, wenn am Dataset irgendwelche Data-aware components hängen. Etwa ein Grid. Wird z.B. ein Datensatz im Grid editiert und man wechselt den Datensatz, schickt das Dataset die SQL-Anweisung an den Server, die in Dataset1.UpdateSQL steht, incl. Post. Warum sollte man also seine SelectSQL ständig verbiegen, wenn man für sämtliche Schreibvorgänge eigene Properties hat, die man bequem parallel zueinander definieren kann?

Natürlich kann man in SelectSQL beliebige Statements reinschreiben, die dann auch ausgeführt werden, sagte ich ja auch schon, aber warum? Wenn in UpdateSQL, InsertSQL, DeleteSQL die entsprechenden SQL Anweisungen stehen, reicht ein Post irgendwo im Code, und es wird brav gespeichert. Daher verstehe ich auch nicht, lieber Hansa, warum es jetzt auf ein Query hinauslaufen soll, das eignet sich gerade nicht zum Schreiben in die DB, dann nimm lieber eine reine SQL Komponente, allerdings kann man an diese keine datensensitiven Objekte ranhängen.

Was ich gestern Hansa geantwortet habe:

Code:

ich will                             geeignete Komponente 
--------------------------------------------------------- 
Daten über Grid manipulieren         TIBDataset 
Daten in Grid nur anzeigen           TIBQuery 
direkt mit der DB arbeiten           TIBSQL

TIBSQL hat daher auch ExecSQL, da es zum direkten Ausführen von SQL Befehlen konzipiert wurde. Wenig Speicherbedarf und um ein zigfaches schneller als die beiden anderen Komponenten. Du kannst mit TIBSQL etwa in allen Datensätzen einen Wert in ein Feld schreiben. Selbst, wenn das tausende sind, zuckt der Server höchstens mal kurz. Klar, das geht auch mit Queries, aber die sind nun mal zur Datenansicht, also für den Lesezugriff da, schleppen auch alles mit, was man dafür braucht, also wozu dann instanzieren für ein einfaches INSERT...?

[Lemmy]

Hi Harrybo,

ja, Du hast recht, aber nur fast!

Jeff Overcash hat einmal gesagt, dass die TIBQuery nur aus kompatibilitätsgründen bei IBX dabei ist, anstelle der TIBQuery sollte immer die TIBDataSet verwendet werden. Es kann aber auch sein, dass sich inzwischen der Stellenwert die TIBQuery geändert hat und ich das nicht mitbekommen habe.....

Natürlich ist die TIBSQL schneller, da diese weniger Overhead mit rumschleppen muss als die TIBDataSet. Hast Du schon mal mit Int64 in deiner Datenbank gearbeitet?? Sobald Du diese Werte bei ParamByName zuweisen willst, wird es beim TIBSQL/TIBStoredProcedure richtig aufwändig, die diese beiden Kompos keine Int64-Felder unterstützen!!! Aus diesem Grund arbeite ich (fast) nur noch mit TIBDataSet....

Grüße
Lemmy

[Hansa]

Hi Leute,

das ganze geht jetzt und es sieht so aus, daß der Hund bei FIBplus begraben ist. 8) Ist aber nichts schlimmes. Man hat mir gesagt, ich solle gefälligst pFIBQuery verwenden ! Jetzt habe ích das gemacht und siehe es geht alles wie gewünscht. D.h. ich setze die SQL-Statements und mit ExecQuery kommt dann das richtige Ergebnis.