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...?