ZEOS im Produktiveinsatz mit FB ?

[bepe]

Zitat:

wieso muss das Rollback angepasst werden ?

Weil das Rollback ebenfalls nur retaining ist.

Zitat:

Warum dauert das Open so lange ?
Oder anders gefragt, dauert es denn mit ibplanalyzer kürzer ?

Warum das Open solange dauert wissen wir nicht. Wir haben alles (an Eigenschaften) ausprobiert aber ohne Erfolg. Muss gestehen IBPlanAnalyzer sagt mir spontan nichts aber alles andere ist schneller. Auch mit dem IBCursor kommt man auf gute Werte. Aber der kommt wegen der datensensitiven Steuerelemente nicht in Frage.

[Hansa]

Zitat von hoika:

also muss ich UIB nehmen.

Wer zwingt Dich denn dazu ? Sind ca. 200 EUR eine unüberwindliche Hürde, dann ja.

Vorab : Zeos ist bei mir ziemlich schnell aus dem Rennen gewesen, und zwar hauptsächlich wegen der Multi-DB Unterstützung. Ich kann mir nicht vorstellen, daß in einer der unterstützten Datenbanken eine optimale Performance erreicht werden kann und alle Funktionen überhaupt implementiert sind. Da ein Endanwender nur selten nach der DB frägt ist das IMHO Blödsinn Habe das jedenfalls noch nicht erlebt.

Zitat von hoika:

kann eine Connection wirklich nur eine Transaktion bedienen ?

Da will ich jetzt wissen, was unter Connection genau gemeint ist. Damit kann doch wohl nicht die Database-Connection gemeint sein ?

[bepe]

Zitat:

Zeos ist bei mir ziemlich schnell aus dem Rennen gewesen, und zwar hauptsächlich wegen der Multi-DB Unterstützung. Ich kann mir nicht vorstellen, daß in einer der unterstützten Datenbanken eine optimale Performance erreicht werden kann und alle Funktionen überhaupt implementiert sind.

Ich will dich ja nicht belehren aber eine Entscheidung von der eigenen Fantasie/Vorstellung abhängig zu machen halte ich doch für zweifelhaft.

Zum Thema Performance kann dir z.B. verraten das Zeos (zumindest beim Firebird) eine Top-Platzierung schafft. Vergleichen wir Zeos mit den IBObjects, eine Sammlung nur für die Verbindung mit dem Firebird, ist Zeos überlegen/schneller. In einigen Belangen/Konstellationen sogar deutlich schneller. Nehmen wir mein weiter oben erwähntes Open-Problem: Zeos ist eine ganze Sekunde schneller.
Ein anderer Vertreter UIB hingegen lässt auch Zeos weit hinter sich. Aber die Ursache dafür liegt wohl nicht an der Spezialisierung, sondern am Komfort. Die IBO's haben viel "Komfort-SchnickSchnack", was die IBO's wohl etwas träge macht. UIB konzentriert sich auf das Wesentliche.

Funktionsumfang könnte ein Punkt sein. Aber Zeos beherscht alles was du auch mit den Standard-Komponenten in Verbindung mit der BDE kannst. Zumal die Anforderung bei einem einfachen Programm nicht so hoch sein können. SQL-Anweisungen kannst du mit jeder DB-Sammlung absetzen. Und damit hast du alle Funktionen implementiert.
Möchtest du ein Wartungstool oder ähnliches machen, sieht es natürlich anders aus. Du hast keine Backup/Restore-Komponenten, kannst keine Benutzer verwalten oder Performance-Analysen machen. Wobei sich gbak, gfix und gsec problemlos in das eigene Programm "integrieren" lassen

Zitat:

Damit kann doch wohl nicht die Database-Connection gemeint sein ?

Doch. Wie bei der guten alten TDataBase befindet sich das Transaktions-Handling in der DB-Komponente.


edit:
Nachdem ich mir UIB und Zeos angesehen habe, möchte ich doch noch meine Meinung zum Ursprung des Themas kund tun.

Zitat:

Ich will mich jetzt so langsam von der BDE verabschieden (jaja Wink ),
und würde ZEOS wegen Multi-DB-Fähigkeit UIB vorziehen.

Bei beiden hätte ich ein Stück weit ein ungutes Gefühl. Ich habe sie noch nicht Produktiv eingesetzt und habe nicht gehört das es jemand anderes tut. Was wiederum seine Gründe haben muss: Sie sind unbekannt, sie sind kostenlos oder sind einfach schlecht. Ich weiß es nicht.

UIB konnte mich durch die Geschwindigkeit und durch das stetig wachsende Zubehör begeistern. Schade finde ich es das keine Query existiert welche Daten bearbeitet und datensensitive Steuerelemente bedient. Vermissen tue ich auch die Möglichkeit gejointe Datenmengen zu bearbeiten. Beides kann zwar durch ein zusätzliches Packages, in Form einer weiteren Komponente, nachgerüstet werden, aber das wirft bei mir Fragen auf: Warum ist es ein extra Package? Kommt es von einem Dritten? Wie gut ist es integriert und wie Update2Date wird es gehalten?
Mein Fazit: Sehr interessant. Aber einsetzen würde ich sie nur in kleinen Programmen oder in Modulen in denen es auf Geschwindigkeit ankommt (zumindest bis sie mein Vertrauen erweckt haben).

Ignoriert man das Commit-Retaining, kann ich zu Zeos nichts negatives berichten. Sie sind schnell und lassen nichts vermissen. Begeistert hat mich die Möglichkeit gejointe Datenmengen bearbeiten zu können. Aber nicht nur die Hauptdatenmenge sondern auch die gejointen Daten. Mit einer Query und auf einen Schlag. Ebenfalls erfreulich: Multi-DB. Es bleibt, bei einer DB-Umstellung, natürlich jede menge Arbeit zu erlerdigen (Trigger, SP's, DB-Dialekte), aber ein anderer Teil an Arbeit entfällt.
Mein Fazit: Ich würde es auf ein Versuch ankommen lassen.

[Hansa]

Zitat:

Zum Thema Performance kann dir z.B. verraten das Zeos (zumindest beim Firebird) eine Top-Platzierung schafft. Vergleichen wir Zeos mit den IBObjects, eine Sammlung nur für die Verbindung mit dem Firebird, ist Zeos überlegen/schneller...

Ich kann Dir auch was verraten : vertraue nur der Statistik, die du selber gefälscht hast. Kanns kaum glauben, aber wenn es tatsächlich nur möglich ist, eine einzige Transaction pro DB mit Zeos zu machen, welchen Sinn macht dann noch ein Performancetest ? Bin hier noch dran an den Transaction-Isolation-Levels rumzuschrauben. Wie soll denn das gehen mit einer einzigen Transaction ? IBO ist auch längst aus dem Rennen. Waren mir zu seltsam in der Handhabung. Verwende jetzt FIBplus und fertig. Ah ja, was ist eigentlich gemeint mit "Komfort-Schnickschnack" ?

Da ist ja noch mehr :

Zitat von bepe:

Funktionsumfang könnte ein Punkt sein. Aber Zeos beherscht alles was du auch mit den Standard-Komponenten in Verbindung mit der BDE kannst. Zumal die Anforderung bei einem einfachen Programm nicht so hoch sein können. SQL-Anweisungen kannst du mit jeder DB-Sammlung absetzen. Und damit hast du alle Funktionen implementiert.

BDE ? Dann reden wir besser über den VW Käfer. Das ist doch gar kein Vergleich. Spät gemerkt, daß die schon jahrelang verbuddelt ist ? Was ist unter "einfachen" Programmen zu verstehen ? Aber egal. Ich frage ja nur mal hier, quasi als Zwischenfrage, wie es denn mit Zeos mittlerweile aussieht. Eben um einen Gesamtüberblick zu behalten. Konkret noch eine Knackpunkt-Frage : wie siehts mit den neueren features ab FB 1.5 aus ? Nehmen wir mal die SavePoints, also eine Art gestaffelter Transaktionen. Geht das mit Zeos in Delphi ? IBO wäre auch interessant zu wissen. Also so was :

Delphi-Quellcode:

Transaction.SetSavePoint ('SAVEPOINT1');
...  // weitere Eingaben
Transaction.SetSavePoint ('SAVEPOINT2');
...  // weitere Eingaben

Transaction.RollbackToSavePoint ('SAVEPOINT1'); // uff, verhauen->zurück. Am besten sogar zu Savepoint1
...  // ab da wieder weitermachen
Transaction.Commit; // endlich fertig

[hoika]

Hallo,

nette Diskussion habe ich angestossen.
Aber wie ich schon selbst festgestellt habe,
werde ich erst mal die Finger von ZEOS lassen.

Zu Transaktionen:
ja ein TConnection (also eine Client-Verbindung zur Datenbank, also eine TDataBase der BDE)
kann unter ZEOS nur eine Transaktion gleichzeitig bedienen.
Eine TConnection -> TTransaction -> TQuery gibt es nicht, es wird alles über die TConnection angestossen,
wie man es halt von der BDE gewohnt.
Natürlich können mehrere Transaktionen gleichzeitig laufen, dann aber über
je eine TConnection (also DB-Verbindung).

Apropos BDE, ich weiss, dass sie tot (deprecated) ist.
Aber ich habe hier ein Programm mit ~ 900000 Zeilen Code zu warten,
dass läuft halt noch damit.
Zum damaligen Zeitpunkt (1995) gab es weder ibx, noch fiblus usw ;(


Für mich KO-Kriterium ist allerdings, dass es keine HardCommits gibt,
jedes Conn.Commit erzeugt ein Commit Retaining !
Schön für die Performance, wenn man die Connection nach getaner Arbeit
sofort wieder schliesst. Lasse ich die aber offen, weil ein Connect ohne
Connection-Pool lange dauert, steigt der FB irgendwann aus.
Die Lösung im ZEOS-Forum heisst "Mache ab- und zu die Connection zu und wieder auf"

Das schlimme ist, es lässt sich hält nicht einstellen.
Die BDE hatte immer ein hardcommit gemacht (es sei denn, man benutzt die driver flags).


Heiko

[bepe]

Die Frage verstehe ich nicht:

Zitat:

eine einzige Transaction pro DB mit Zeos zu machen, welchen Sinn macht dann noch ein Performancetest ?

Moment..du willst damit sagen, dass dir eine Transaktion nicht reicht!? Dann macht die Aussage sinn. Aber das trifft auf mich nicht zu.

Zitat:

Ah ja, was ist eigentlich gemeint mit "Komfort-Schnickschnack" ?

Du kannst in der DB-Komponente z.B. die "Generator-Links" eingeben. Das sieht so aus "Tabelle.Feld=GeneratorName". Und wann immer ein Datensatz in der Tabelle angelegt wird, wird der Generatorwert ausgelesen und zugewiesen.

Zitat:

BDE ? Dann reden wir besser über den VW Käfer. Das ist doch gar kein Vergleich. Spät gemerkt, daß die schon jahrelang verbuddelt ist ?

Das nimmst du sofort zurück! Das würde implizieren das ich TurboPascal auch von der Platte tilgen kann (Kann ich aber nicht wegen ausreichend vieler aktiver Installationen, bei nicht updatewilligen Kunden ). Nein, im ernst: Ich wollte ja nur veranschaulichen wie das mit den Transaktionen funktioniert.

Zitat:

Was ist unter "einfachen" Programmen zu verstehen ?

In dem Kontext z.B. ein 1,5 millionen Zeilen umfassendes WWS. Oder pauschal ausgedrükt: Jedes Programm welches nicht zwingend die Funktionalität von gbak, gsec und gfix benötigt.

Zitat:

Nehmen wir mal die SavePoints, also eine Art gestaffelter Transaktionen. Geht das mit Zeos in Delphi ? IBO wäre auch interessant zu wissen.

Nein, in den aktuellen Versionen wird das nicht unterstützt. Die IBO's haben "SavePoint-Funktionen" aber dahinter verbirgt sich nur das CommitRetaining.

Zitat:

nette Diskussion habe ich angestossen.

Allerdings. Teilweise vielleicht etwas am Thema vorbei, aber Interessant sind die unterschiedlichen Meinungen/Anforderungen alle mal.

[hoika]

Hallo,

ja ich hätte gern 2 Transaktionen
In diesem Fall ist es so, dass ich mit pessimistischen Sperren arbeiten möchte,
also z.B. Person wird gesperrt, bevor sie bearbeitet werden kann.
Jetzt könnte man das per

select for lock (oder so ähnlich machen)
oder man schreibt innerhalb einer Transaktion update person set id=:id
um das innerhalb der Transaktion schon zu sperren.

Ich schreibe aber ein Sperrprotokoll mit,
wie drinsteht personalid=5 ist gesperrt.
Die Sperre wird per Timer (oder Thread) alle 1 min aktualisiert.
Und da isses
Diese Aktualisierung soll natürlich in einer eigenen Transaktion (mit read committed)
laufen und darf andere DB-Sachen nicht beeinflussen.

Per BDE und ZEOS muesste ich jetzt eine neue Connection (TDataBase/TConnection) erzeugen.
Per IBX/UIB wird einfach eine 2. Transaktion erzeugt.
Das heisst, kein neues Connect.


Heiko

[Hansa]

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.

[hoika]

Hallo,

ZEOS benutzt nur Commit Retaining.
Es ist nichts anderes einstellbar !

Zum Locken.
Ich will ja gar nicht den Datensatz physisch locken,
ich locke über eine Sperrtabelle.
Lock heisst, dass das Programm z.B. eine Person sperrt,
damit ein anderer Client nicht gleichzeigt schreibend auf Daten zugreifen kann.

Eine Person wird auch dann gesperrt, wenn z.B. ihre Urlaubsdaten bearbeitet werden,
obwohl die in einer ganz anderen Tabelle sind.


Das mit dem
select for update war ja nur so eine ähnliche Sache.

Naja, muss ich wohl die 200 EUR am Bahnhof erschnorren

3 Monate zum Umstellen sind ilosorisch (sieht komisch aus das Wort )
Das geht eh nur im laufenden Betrieb,
also bridge pattern einbauen.
Das dumme ist, es sind ein "paar" TTable auf Forms dabei ...

Ich hatte mir dass so gedacht

TBaseQuery = class

end;

TBdeQuery = class(TBaseQuery)
end;

TFIBPLusQuery = class(TBaseQuery)
end;


und dann über class factory die gewünschte Query erzeugen.

Ich muss in Notfällen immer schnell zur BDE zurückkommen können.


Heiko

[raiguen]

Zitat von hoika:

... ilosorisch (sieht komisch aus das Wort )

So wie du es schreibst, sieht's in der Tat komisch aus
Besser ist es so: illusorisch
Ich weiß, sprachliche Feinheiten Nix für Ungut