Zitat von
bepe:
Die Frage verstehe ich nicht:
eine einzige Transaction pro
DB mit Zeos zu machen, welchen Sinn macht dann noch ein Performancetest ?
Wieso Du nix comprendez ?
Habe folgendes gemeint : ein Performancetest macht doch eigentlich nur dann Sinn, wenn etwas überhaupt zu gebrauchen ist. Domo Sokrat möge mir verzeihen, aber das mit einer einzigen Transaction versetzt Zeos immer noch den absoluten K.O. Stop, muß das etwas relativieren : in Mehrplatzumgebung. Liegt die Wahrscheinlickeit nur bei 1 %, daß es, und zwar über Jahre gesehen, doch nicht nur Einzelplätze werden, dann würde ich darauf verzichten. Unter Produktiveinsatz verstehe ich dabei mehr den geschäftlichen Bereich. Aber wer Notebook mit WLAN hat, der soll mal durch die Gegend fahren. An jeder Ecke sind WLANs.
IMHO kann man mittlerweile Netzwerkunterstützung nicht mal in Privathaushalten einfach so ignorieren.
Das hat doch alles nichts mit einer einzigen möglichen Transaktion zu tun ? Und ob. Nur kurz : es geht um Deadlocks, Datenkonsistenz usw. Natürlich kann man sofort Committen, aber dann kann man jegliches Rollback vergessen. Habe nicht umsonst nach RollBackToSavePoint gefragt. Vermute mal, daß bei Zeos verstärkt CommitRetaining zum Einsatz kommt. Nur, was soll man denn mit sowas auf Dauer ?
Gut, kann jetzt nur genau sagen, wie es bei FibPlus aussieht. Woanders (außer bei Zeos) dürften zumindest aber mehrere Transactions möglich sein. Handelt es sich sogar um viele Netzwerk-User, dann ist es unbedingt nötig zumindest 2 Transactions zu benutzen. Eine lesende und eine schreibende. Die lesende kann ruhig länger dauern (die berühmte Kaffeepause, die viel länger wird als geplant). Dann stellt man die Isolation-Levels der Transactions nach jeweiligem Bedarf ein und irgendwann gehts dann wie gewünscht. Aber auch im Netz zu 100 %. Wichtig hierbei ist jedoch, daß alle
DB-Aktivitäten im Kontext dieser beiden Transaktionen laufen. In FIBplus hat man bei einem Dataset z.B. außer der Standard-Transaction im
OI auch eine UpdateTransaction. Die muß man eben den Datasets zuordnen. Eine weitere Database-Komponente mit anderer Transaction nützt da überhaupt nichts.
Aber ich verstehe auch einiges nicht. 8) Z.B. das :
Zitat:
Moment..du willst damit sagen, dass dir eine Transaktion nicht reicht!? Dann macht die Aussage sinn. Aber das trifft auf mich nicht zu.
Wieso redest Du dann an anderer Stelle von einer "größeren kommerziellen Anwendung" ?
Und hoika, bei 900000 Zeilen dürfen die
DB-Zugriffskomponenten keinen Cent kosten, oder wie ?
Was kostet es denn, 4 Wochen das Programm abzuändern auf Zeos, dann zu merken, daß es nicht geht, dann nochmals 3 Monate für UIB aufzuwenden, wo die Hälfte fehlt ? Nur, um 200 EUR zu sparen ?
Kurz noch zu Deinem beabsichtigten Locking. Guck Dir mal die Transaction-Isolation-Levels genauer an. Locking braucht man eigentlich bei einer MGA-Architektur nur selten. Habe einen Fall, da wirds wohl verwendet werden. In FIBplus habe ich hierzu eine function Dataset.LockRecord und fertig. Guck Dir das doch auchmal an. Die Trial ist zeitlich unbeschränkt und in der Funktionalität bei relativ unwichtigem eingeschränkt. Falls Du damit anfängst, das Programm zu modernisieren und Dich stört beim konkreten realen Einsatz der Splash-Screen, der bei der Trial kommt, dann treibe bis zur Fertigstellung irgendwie die 200 EUR auf.
Sehe gerade IBX ?
FB-Locking ? Sie habens doch gesagt, nix
FB ! Also besser gleich vergessen.