...Nachdem ich die entsprechenden Krücken eingebaut habe (eigene Abfrage eines Generators und dessen ID verwenden)
Also du kannst froh sein, eine Datenbank zu benützen, die Generatoren kennt.
In anderen
DBMS müsstest du den Generator künstlich nachbilden.
Einen Generator zu verwenden ist keine Krücke, sondern eigentlich sind AUTOINC-Felder die Krücke.
AUTOINC-Felder wiegen den Programmierer in der falschen Sicherheit, er müsse sich nicht um die Primärschlüsselfelder kümmern.
Sobald man aber abhängige Tabellen hat, entsteht das Problem, dass man den Wert des Feldes nicht kennt.
... Es handelt sich um ein per Firebird mit "computed by"-Ausdruck berechnetes Zeitstempelfeld. ... Ich möchte die Datenbanklogik soweit wie möglich in die Datenbank verlagern und Komponenten, die das auch berücksichtigen.
Es gibt 3 Haupt-Gründe weshalb man Logik in die Datenbank verlagert:
1.) Geschwindigkeit. Manche Dinge werden auf der Datenbank wesentlich schneller ausgeführt als über die Anwendung
2.) Mehrere verschiedene Anwendungen greifen auf die gleiche Datenbank zu
Durch Verlagerung von Logik in die Datenbank vermeidet man das Implementieren der Logik in mehreren Anwendungen.
Falls unbekannte neue Anwendungen auf die Datenbank zugreifen profitieren diese automatisch
3.) Schutz der Datenbank vor inkonsistenten Daten; Erzwingung von Integritätsregeln
Ich vermute mal, dass in deinem Fall keiner der Gründe zutrifft und dass du nur deshalb das "computed by"-Feld verwendest um deine Anwendung etwas zu vereinfachen.
Man müsste jetzt die genaue Tabellenstruktur und das gewünschte Ergebnis kennen, aber mit einer
SQL-
Query oder einem CalculatedField (lokal im Dataset berechnet) kommst du auch ans Ziel.