ZEOS im Produktiveinsatz mit FB ?

[hoika]

Hallo Martin,

auch mit FB?
Wie hast du das mit dem commit retaining gelöst ?
Laut Andreas Kosch gibt es doch damit Probleme.


Heiko

[Hansa]

Soweit ich das sehe, hat hier in dem Thread noch kein einziger Frischling was geschrieben. Anscheinend trauen die sich nicht. Die werden schon wissen warum.

Warum besteht eigentlich überhaupt Handlungsbedarf ? Was ist denn so wichtig, dass die BDE weg muß ? Sind das konkrete oder längerfristige Überlegungen ? Auch wenn hier (zurecht) vor einem Einsatz der BDE (mittlerweile) gewarnt wird. Es gilt immer noch : "Never change a running System" Wobei ich hinzufügen würde "too much". Das ganze darf aber nicht zum Selbstzweck entarten. Ist der Fall der, daß mit der Zeit immer mehr Kompromisse eingegangen werden müssen, dann muss irgendwann wohl auch mal Tabularasa gemacht werden. Wenn schon, dann aber richtig. Sieht aus, als wäre das Deine momentane Sicht der Dinge. IMHO fängst Du aber trotzdem halbherzig an. Zuallererst wird eine kostenlose Komponentensammlung gesucht. 8) Ich habe das umgekehrt gemacht : zuerst mal geguckt, was es denn überhaupt gibt. Dann getestet und als absehbar war, was gut ist, da habe ich mal geguckt was die Alternativen denn überhaupt kosten.

Jetzt betrachte ich das mal in diesem Zusammenhang :

Zitat von hoika:

Cheffe hat immer noch den MS-SQL im Hinterkopf.

Wo hat denn der das her ? Wahrscheinlich von irgendwem aufgeschnappt. Bei mir wäre der Fall wohl schon längst erledigt. Frage ihn doch einfach, was ihm lieber wäre : einmalig ca. 200 EUR für anständige Zugriffskomponenten zu investieren und eine kostenlose DB zu benutzen, oder ca 2-3000 EUR für 10 User DB (mehr => teurer), wobei vom Programm her dasselbe heraus käme. Sage ihm am besten noch, es ginge auch völlig ohne Investition, aber das wäre so mühsam, daß Deine Freizeit dafür leider zu knapp sei.

[hoika]

Recht hast du !

Ich will mich ja gerade um den Test rummogeln,
indem ich gefragt habe, gerade weil ja ZEOS multidb-fähig ist.

Naja, ich werde erst mal meine bridge-pattern Query zusamenbauen,
und die BDE-Query als erste Option dort reinpacken.

Mein Problem ist ja leider auch,
dass nicht alle Routinen auf Query zurückgreifen,
dass will ich in dem Zusammenhang auch noch prüfen/ändern.
Jedes Ändern erzeugt wieder Tests
(dunit ist fein, wenn alle Routinen dort drin wären ...)

*seufz*

Ah ja, ist bei fibplus dann der Quellcode dabei ?


Heiko

[mschaefer]

Hallo Heiko,

über die Sperrtabellen hasst Du den einen Teil selbst schon gelöst. Die Frage ist jetzt nur noch was passiert, wenn Änderungen verworfen werden und da bin ich recht trivial aber wirkungsvoll:

CommitRetaining

Zitat von Marcel Gascoyne:

Zuerst die Daten per SELECT lesen und lokal speichern, statt die Transaktion offen zu halten. Änderungen werden dann per UPDATE oder INSERT in einer neuen Transaktion gespeichert.

In vielen Systemen hat man "many read and some write" Zugriffe und da kann man mit der Methodik gut arbeiten. Erst bei viel konkurrierenden Schreibzugriffen können die FIB-Komponenten ihren Komfortvorteil wirklich ausspielen.

Einen klaren Vorteil haben die Zeos-Komponenten: Die Datenbank kann nahezu transparent getauscht werden, solange man keinen speziellen SQL-Syntax einsetzt.

Grüße // Martin

[Hansa]

Zitat von mschaefer:

...Einen klaren Vorteil haben die Zeos-Komponenten: Die Datenbank kann nahezu transparent getauscht werden, solange man keinen speziellen SQL-Syntax einsetzt.

hmhm, wo liegt denn da der Vorteil ? Spezielle Syntax ? Man kann die auch einsetzen, um eventuelle Vorteile direkt zunichte zu machen.