das machen wir regelmäßig immer so, aber das hängt wenig mit der Implementation zusammen,
schon gar nicht mit Fähigkeiten von FB3.
Beispiel: In unserer Software wird für die Volltextsuche ein Suchindex für alle Datensatze
aufgebaut, die sich nach ganz bestimmten Regeln im Auftragskontext befinden. Außerdem wird
der Deckunsgbeitrag immer dann im Auftrag aktualisiert, wenn einzelne Positionen angelegt,
geändert oder gelöscht werden. Auch dabei wird einiges an Datensätzen durchgerödelt.
Für einfache Aufträge ist das sehr einfach, da macht man das eben on the fly, während man
die Daten eingibt. Bei komplexen Aufträge mit dutzenden Fertigungsaufträge, hunderten
Arbeitsgängen und Materialpositionen wird das schon ziemlich ekelig für den Anwender,
insbesondere wei ihn das selten sofort interessiert.
Wenn das also ein Trigger macht, wird das bei jeder Änderung immer gleich im Kontext des
Anwenders gemacht oder mit anderen Worten: Der Anwender wartet bei jede noch so banalen
Änderung auf alles, was irgendein beteiligter Trigger für wichtig hält.
Wir erstellen daher Trigger, die sobald sich was in den relevanten Daten ändert, den Auftrag
in eine Jobtabelle eintragen, falls der da nicht eh schon drin steht. Bei Löschen eines
Fertigungsauftrags mit 10 Arbeitsgängen würde ien Arbeitsgangbasierender trigger auch 10 mal
ausgeführt werden, auch wenn der Löschvorgang in einer Transaktion ausgeführt wird. Das
sieht man sehr gut in der Trace
API.
Mit diesem Insert in die Jobtabelle wird dann auch gleich ein Event ausgelöst, dieses aber
erst beim Commit, also nur ein mal. Auf dem
DB Server läuft ein Script mit der ibescript.exe
mit ibec_waitforevent oder eine beliebige exe oder ein sonstiges Programm, das die auf diese
Event reagiert, was auch immer das bedeutet. In der Jobtabelle steht dann zum Beispiel drin
EXECUTE PROCEDURE BRPSEARCHUPDATE(123456);
oder
MeinProgramm.exe P1=123456
Wenn der Befehl erfolgreich abgeschlossen wurde, löscht das Script/die Exe auch gleich den Eintrag
in der Jobtabelle (und kann bei Bedarf dort im Delete Trigger wieder ein Event auslösen, der
deine Client Software veranlasst, den Bildschirm zu aktualisieren, wenn der Anwender nicht in der
Zwischenzeit auf einen anderen Bildschirm umgeschaltet hat.
Ob du auf diesem Wege serverseitig komplexe Datenoperationen als Exe implementierst und in deinem
Client nur den passenden Eintrag für die Jobtabelle implementierst, ist dann nur noch die Frage deiner
Architektur, aber keineswegs abhängig davon, das Firebird in irgendeiner Form deinen Quelltext
oder deine
DLL direkt einbinden könnte. Großer Vorteil so einer Vorgehensweise ist dabei auch
die Teamfähigkeit in der Entwicklung. Der Front End kann weiterentwickelt werden, obwohl die
Implementation im Backend ggf noch gar nicht fertig ist oder vielleicht sogar Kundenabhängig
variiert werden kann. Die Implementation via Webfrontend oder für mobile Systeme ist dann auch
ein einfaches, weil der dann auch ggf nur den Eintrag in deine Jobtabelle beherrschen muss.
Ich gehe nicht davon aus, das die Implementation externer Prozesduren in Firebird ohne externe
Client in irgendeiner Weise asynchron laufen werden, weil dann das gesamt Transaktionskonzept
problematisch sein wird.
Nun denn, deine angestrebte Idee lässt sich schon heute umsetzen und wird sicherlich gerade bei
größeren Systemen die Anwender erfreuen, weil die Reaktionszeit der Software im Dialogbetrieb
minimiert werden kann.