Firebird 3.0

[hanspeter]

Danke erst mal für die ausführlichen Antworten.
Das ist sehr interessant und beruhigt mich erst einmal.
Letztendlich ist es mir auch lieber wenn es länger dauert und dafür eine stabile Version vorliegt.
Delphi ist da wohl eher ein Beispiel für das Gegenteil. Beta-Test beim Kunden und zuletzt 2 Versionen pro Jahr.

Bezüglich der Geschwindigkeit und Transactionssteuerung von Stored procedure und Firebird events hatte ich in der Vargangenheit weniger gute Erfahrungen gemacht und diese Lösung wieder zurückgebaut.
Was ich als Lösung anstrebe, ist die gesamte Verarbeitung auf dem Server auszuführen und die Clients abzuspecken.
Auf dem Server soll ein Programm laufen. Diese erhält über stored Procedure eine Aufgabe zugeteilt und legt diese erst mal auf einem Stapel ab.
Die Abarbeitung erfolgt sequentiell. Das Programm kann wie ein Client mit Transactionssteuerung arbeiten und sendet nach der Fertigstellung einer Aufgabe einen Event.
Das hatte ich schon mal mit stored procedure gelöst, dann diesen Weg wieder aufgegeben.
Mit FB 3.0 sollte die Lösung realisierbar sein.


Mit Gruß Peter

[IBExpert]

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.

[hanspeter]

Hallo Holger,

vielen Dank für das Beispiel.
Es entspricht in etwa der Architektur, welche ich mir vorstelle.
So eine Architektur hat nach meiner Meinung noch einen weiteren Vorteil.
Da sie Input/Output nur in der Datenbank hat, lässt sie sich leichter testen.
Der Test läßt sich besser mit DUnit automatisieren.
Funktionieren Events eigentlich jetzt in Firebird problemlos oder ist hier noch etwas zu beachten?
Ich habe 2006 eine Software unter Livebedingungen im laufenden Betrieb von Event auf polling umstellen müssen.
Die Eventsteuerung funktionierte nach dem Programmstart einige Minuten bis zu einer halben Stunde und setzte dann aus unerklärlichen Gründen aus.
2006 war glaube ich noch FB 1.5. Ich meine gelesen zu haben, das es da Probleme gab und die erst mit FB 2.1 wohl beseitigt wurden?
Ich habe jetzt noch einen Rechner, der mit Windows NT4 läuft. Der hatte mit events masive Probleme. (Ein schweinisch teurer Schriftgenerator für Fernseheinblendungen.)
Im Moment verwende ich allerdings keinen dedizierten Server.
Da das System für eine Veranstaltung aufgebaut und danach wieder abgebaut wird, verwende ich einen Client (immer den am besten beaufsichtigten Rechner) als Server.
Das Netzwerk ist teils temporär verlegtes Kabel, teils aber auch bis zu 700 m WLAN.
Insbesondere im WLAN hatte ich Probleme mit events.

Mit den besten Wünschen für einen guten Rutsch und ein gesundes neues Jahr

Peter

[tsteinmaurer]

Zitat:

Funktionieren Events eigentlich jetzt in Firebird problemlos oder ist hier noch etwas zu beachten?

Mit jedem Firebird Release wurde etwas an den Events gefixt/verbessert. 1.5 hatte da noch so manche Probleme. Mit 2.5.2 sind mir aktuell keine Probleme bekannt. Grundsätzlich muss man halt beachten, dass Per-Default, die Eventkommunikation über einen Random TCP-Port geht, sofern man RemoteAuxPort (oder so ähnlich) in firebird.conf nicht konfiguriert. D.h. hier kann man in Firewall-bedingte Probleme laufen. In früheren Firebird Version konnte das zur Folge haben, dass der komplette Firebird Server nachfolgende Requests blockierte etc.

Wichtig ist auch, dass man client-seitig eine stabile Event-Komponente verwendet. Eine weitere Variable kommt hinzu, wenn client-seitig das Ganze Multi-threaded bzw. als Windows-Service eingesetzt wird. D.h. es muss nicht immer notwendigerweise ein Event-Problem auf der Serverseite durch einen Bug im Firebird Server sein.

[Dumpfbacke]

Hallo Leute,
noch eine Frage zu FB 3.0 von meiner Seite. Es sollte doch bei der Version ein Join über mehrere Datenbanken gehen. Ist dem noch immer so ? Dieses ist das einzigste was mir eigentlich bei FB noch fehlt

Tanja

[tsteinmaurer]

Leider nicht in einem Single-SQL-Statement, sondern via EXECUTE STATEMENT in PSQL. Aber das gibt es schon seit 2.5.

[Dumpfbacke]

Zitat von tsteinmaurer:

Leider nicht in einem Single-SQL-Statement, sondern via EXECUTE STATEMENT in PSQL. Aber das gibt es schon seit 2.5.

Könntest du mier hierzu ein kleines Beispiel bitte geben wie man so etwas macht ? Man das wäre ja schön wenn es schon mit 2.5 gehen würde.



Danke schon einmla Tanja