Es gibt einige Zugriffskomponenten, die bieten direkt eine RefreshAfterPost-Option an, wo sie automatisch ein RefreshRecord nach einem Post ausführen.
Welche Komponente meinst du hier konkret? In TFDQuery oder TDBGrid kann ich eine solche Option nicht finden. Es geht auch wirklich um eine Option oder um irgendeinen Event?
Der Insert-Trigger wäre nicht unbedingt nötig, denn dafür kann man die Default-Werte doch bestimmt auch direkt in der Tabelle definieren.
Wie sollte ein Defaultwert für ein Datum/Zeit-Feld (wie "Created"/"Modified") aussehen? Genauso die Frage, wie es für "CreatedBy"/"ModifiedBy" aussehen könnte? Ich habe in der Richtung schon gesucht, ich bräuchte quasi so etwas wie eine Variable die meine Anwendung setzen kann, also wenn sich ein Anwender an unserer Anwendung (mit der UserId=5) anmeldet, dass ich diese "5" irgendwie an Firebird übergeben kann, dass es bei den Triggern dann für "CreatedBy"/"ModifiedBy" diesen Wert nimmt. Noch völlig unbeleckt von den Möglichkeiten einer
SQL-Datenbank wüsste ich nicht wie das (natürlich möglichst elegant) gehen soll. Klar, ich könnte mir jetzt eine Pseudo-Tabelle basteln "ActiveUser" mit einem einzigen Feld drin "ActiveUserId". Beim Anmelden speichere ich dann in der Tabelle einen Datensatz mit der "5", um im obigen Beispiel zu bleiben. Dann müsste ich in meinen Triggern diese Tabelle "ActiveUser" abfragen. Aber da dreht sich mir irgendwie der Magen um, das wäre doch ziemlicher Unsinn. Wie geht es eleganter/performanter?
SQL-Code:
"Created" TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
"Modified" TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
"CreatedBy" SMALLINT NOT NULL DEFAULT 0, -- CURRENT_USER?
"ModifiedBy" SMALLINT NOT NULL DEFAULT 0,
"CURRENT_USER" ist ein VarChar. Ich möchte auf keinen Fall in meinen Tabellen pro Datensatz eine Zeichenkette speichern mit dem User als String, das hielte ich für keine gute Idee. Außerdem wäre "CURRENT_USER" ja der aktuelle User der Firebird-Datenbank. Ich würde gerne den aktuellen User (als Integer) aus unserer eigenen Userverwaltung verwenden. So mache ich das in unserer aktuellen Anwendung auch. Da ich da aber keine Trigger verwenden kann, wird diese ganze "Created"...-Gedöns alles zu Fuß für jedes einzelne TTable/TQuery das auf einem Formular pappt erledigt. Da dachte ich nun, wunderbar mit
SQL geht das ja alles viel einfacher, das erledigt quasi die Datenbank im Hintergrund.
Aber warum wird Modified schon beim Insert gesetzt, wo es da doch noch garnicht editiert sein kann?
Da hast du Recht, das ist Unfug.
Na dann hoffe ich mal, dass dein Programm im Laufe seines Lebens nicht mehr als 32.767 User kennt
Bei einem Kunden hat es ca. 50 User, bei den anderen <= 20. Da ist man mit dem SMALLINT auf der sicheren Seite.
TIA, Markus