ZEOS im Produktiveinsatz mit FB ?

[hoika]

Hallo #,

hat jemand FB1.5 + ZEOS im Produktiveinsatz (>10 Clients, 24h usw.)
Wann ja, die alte oder neue Version ?

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

Danke


Heiko

[Domo Sokrat]

Hi,

hab' eben gerade Deine Anfrage gelesen. Wir haben eine Applikation auf > 50 Rechnern laufen, die die Zeos in Version 6.1.5 (ohne Patches) nutzt, und auf eine MySQL 4.0.x Datenbank zugreift. Über die Applikation werden ständig Daten neu eingepflegt, geändert und abgefragt, so dass die DB richtig "Stress" hat. Das Teil läuft sehr stabil, was für den Einsatz dieser Zeos-Version auch mit anderen unterstützten Datenbanken (wie z. B. FB 1.5) spricht. Wenn die 6.6'er Version der Zeos "stable" ist, würde ich diese empfehlen, da sind einige Verbesserungen (auch bzgl. FB) drin.

Grüße!

[hoika]

Hallo Domo,

ich habe gerade dein ZEOS-Tut gelesen (6.1.5).
Dort standen ein paar Sachen drin, die mir nicht so gefallen an ZEOS.

- InTransaction existiert nicht
OK, sollte es jetzt in der 6.5 ja

- Commit Retaining
wie hast du das in der deiner App gelöst,
ein hard commit zu machen (das ist ja der BDE-Standard)
ein Connection.Close will ich nicht machen
(Performance)

ich benutze Firebird, da führt wie du so schön gesagt hast,
ein retaining zu performance-Problemen

- Transaction
kann eine Connection wirklich nur eine Transaktion bedienen ?
das ist zwar BDE-Standard, aber ja wohl nicht mehr state-of-art

Danke im voraus
Heiko

[Domo Sokrat]

Hi,

die ersten zwei Punkte haben sich ja quasi "erledigt". Gegen das Retaining (gefällt mir persönlich auch nicht!) kann ich stand jetzt leider nix machen. Die Zeos-Entwickler, die FB nutzen, müssen es noch als gegeben so hinnehmen. Sorry!

Leider kann eine Connection auch nur eine Transaktion bedienen. Damit, dass das nicht mehr "State of the Art" ist, hast Du recht ... Mein Vorschlag: Mach doch mal einen Feature-Request-Thread bei uns im Forum auf und schlag das mal vor für eine der nächsten Versionen :thumb:

Achja - hatte ich vergessen zu erwähnen: Die Applikation, die ich zuvor erwähnt hatte, greift über ZEOS ebenfalls (über das ADO-Protokoll) auf einen MSSQL-Server zu, der extrem unter Dampf steht und jede Menge Transaktionen verarbeiten muss. Funzt wunderbar...

Grüße!

[hoika]

Hallo,

also muss ich UIB nehmen.
oder warten :wall:

*seufz*

Was heisst "feature request bei uns im Forum" ?
delphipraxis ?

Heiko

[mkinzler]

Zitat:

Was heisst "feature request bei uns im Forum" ?

Ich glaube er meint das Zeos-Forum.

[Domo Sokrat]

Hi!

Zitat:

Zitat von mkinzler

Zitat:

Was heisst "feature request bei uns im Forum" ?

Ich glaube er meint das Zeos-Forum.

JOU!!! Sorry für meine undifferenzierte Ausdrucksweise :stupid:

@hoika: Ich hoffe, dass Du trotzdem das Zeos-Projekt im Auge behältst, auch wenn Du zur "Konkurrenz" ;-) gehst ...

[hoika]

;)

Im feature request steht es schon drin.
Antwort "dauert, mal sehen, usw. ..."

Das ist auf jeden Fall das K.O.-Kriterium für die Nutzung mit Firebird.
Ein Connect dauert "ewig",
Wie soll das ohne HardCommits überhaupt funktionieren ?. :wall: :wall:
Und die Tatsache, dass es seit Jahren nicht drin ist,
macht mich stutzig.
Naja, da ich eh bridge pattern nutzen werden,
behalte ich es im Hinterkopf. :zwinker:


Heiko

[bepe]

Da wir mit den IBO's (genauer TIBOQuery) an manchen Stellen auf Performance-Probleme stoßen (eine schlichtes Open, welches nur einen Datensatz liefert, dauert schonmal 1 bis 1,5 sekunden), wurde ich erst Heute gefragt ob Zeos eine Alternative ist. Privat habe ich nur positive Erfahrungen gemacht aber wenn es an ein Projekt mit tausend Anwendern geht...

Nehmen wir einmal ich würde mir das Commit-Problem wegfuschen, was wisst ihr noch Positives bzw. Negatives zu berichten?

Mein Fusch-Ansatz:

Delphi-Quellcode:

unit ZDbcInterbase6;
...
procedure TZInterbase6Connection.Commit;
begin
  if Closed then Exit;

  if FTrHandle <> nil then
  begin
    FPlainDriver.isc_commit_transaction(@FStatusVector, @FTrHandle); // <- meine Änderung
//  FPlainDriver.isc_commit_retaining(@FStatusVector, @FTrHandle);  <- alt
    CheckInterbase6Error(FPlainDriver, FStatusVector, lcTransaction);
    DriverManager.LogMessage(lcTransaction,
      FPlainDriver.GetProtocol, 'TRANSACTION COMMIT');

    StartTransaction; // <- meine Änderung
  end;
end;
...

Wenn ich mir eine eigene DB-Treiber-Klasse ableite (und das Rollback entsprechend anpasse), wie sehr wäre mein Ansatz gefuscht?

Ach ja, wir setzen natürlich Firebird ein. In Version 1.5 und D7.

[hoika]

Hallo,

wieso muss das Rollback angepasst werden ?

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


Heiko
PS: Wie du siehst, stehe auch gerade vor dem Zeos-Problem ;(

[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:

Zitat von hoika

also muss ich UIB nehmen.

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

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 :mrgreen: Habe das jedenfalls noch nicht erlebt.

Zitat:

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 ? :shock:

[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. :mrgreen: 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 ? :shock: Bin hier noch dran an den Transaction-Isolation-Levels rumzuschrauben. Wie soll denn das gehen mit einer einzigen Transaction ? :gruebel: 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:

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. :lol: 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 :lol: ). 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 :-D
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 :wall:
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:

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 ? :mrgreen: 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" ? :shock:

Und hoika, bei 900000 Zeilen dürfen die DB-Zugriffskomponenten keinen Cent kosten, oder wie ? :shock: 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 ? :gruebel: 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. :mrgreen:

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:

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 :roll: Nix für Ungut :wink:

[Hansa]

Habe jetzt mal die Ausgangsfrage neu gelesen. hoika, die Frage stammt ja sogar von Dir ? :shock: Du willst also tatsächlich ein 900.000 Zeilen Programm für mehr als 10 User und im 24 St.-Betrieb auf Zeos umstellen ? Das noch im laufenden Betrieb ? :shock: :shock: Und das sogar noch möglichst umsonst ? Das ist nicht illusorisch, es grenzt eher an Selbstmord. :mrgreen:

[mschaefer]

Moin, moin zusammen

@ Hansa, kohmmt da nicht Lebnsfreude auf: Da hat noch Jemand klare Ziele!

Also Datenmengen sind für Zeos überhaupt kein Problem! Die Notwendigkeit das Locking über eine Sperrtabelle laufen zu lasen macht allerdings einiges an Arbeit. Da gab es mal einen Artikel im ENTWICKLER: Geht aber ist aufwendig. Das machen die FIB-Kponenten doch konfortabler. Wieviel von dem Code sich mit DB-beschäftigt ist vielleicht auch relevant.

Grüße in die Runde // Martin

[Hansa]

Martin meint den Entwickler-Artikel : "Ich sperre, also bin ich !" Na gut, für BDE-Benutzer ist der wohl immer noch brandneu, nämlich Ausgabe 6/2003. :mrgreen: Auch dieses Konzept ist mittlerweile schon überholt. Es gibt ja jetzt "WITH LOCK" in Firebird.

[mschaefer]

:P !: Interbase, Transaktionen verstehen und nutzen,der ENTWICKLER Juli/August 2001 ! :mrgreen: .
Eigentlich ist der Jahrgang schon im Keller, aber die Ausgabe :zwinker: hat es am Licht überlebt!

Viele Grüße // Martin

[Hansa]

Es ist nicht zu fassen, aber 2001, da war doch erst 1-2 Jahre vorher bekannt gegeben worden, daß die BDE nicht mehr weiterentwickelt wird. :gruebel: Die war damals ja dann noch wie neu. :mrgreen:

[GuenterS]

und sie wird immer noch produktiv verwendet...

[Hansa]

Noch so ein alter Sack. :mrgreen: Und nu ? Weil die immer noch da ist, tauchen solche Fragen immer wieder auf. :P

[hoika]

Tja ;(

Was soll ich machen, den Artikel meinte ich übrigens ;)
Das mit dem WithLock will ich ja vermeiden.
Cheffe hat immer noch den MS-SQL im Hinterkopf.
Der hat sowas nicht afaik.

Ausserdem kann man mit der Sperrtabelle schön feststellen,
wer das gerade (seit wann) in Bearbeitung hat.

Übrigens ist der 1. Code 1995 entstanden (damals noch mit Paradox),
nicht 2001, da war die BDE state of the art ...

Dieses "BDE ist out" von den ganzen Frischlingen hier kann ich
nicht mehr hören :wall: :wall:
:angel:


Heiko
PS: In meiner Freizeit baue ich gerade den Code um,
so dass er "später" mal von der BDE wegkommt.

[mkinzler]

Ich fühle mich eigentlich nicht als Frischling :mrgreen:
Das ständige Warnen vor der BDE ist eigentlich gerade an die Frischlinge adressiert, diese links liegen zu lassen, bevor sie sich dann an deren Eigenheiten gewöhnen und diese dann auf "richtige" Datenbanken übertragen wollen.

[mschaefer]

Moin zusammen,

im Groh sind wir uns wohl einig. Wenn die Arbeit mit den Sperrtabellen gemacht ist, warum soll man es dann nicht weiterverwenden? Hat auch Vorteile: Abgespeichterte Zusatzinformationen: Wer speichert, welcher Mode (Readonly/Write usw.). Letzlich kommt es darauf an wie schlüssig dass umgesetzt ist. Zur Ausgangsfrage kann ich sagen, dass ich Zeos mit 5-6 Clients relativ problemlos im Einsatz habe. Geschwindigkeistsmäßig ist das auch noch vertretbar. Wir haben allerdings 1-GBit-Netzwerkkarten, was preislich auch kein Beinpruch ist.

Grüße // Martin

[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. :-D Die werden schon wissen warum. :mrgreen:

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:

Zitat von hoika

Cheffe hat immer noch den MS-SQL im Hinterkopf.

Wo hat denn der das her ? :shock: 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. :mrgreen:

[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:

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:

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 ? :shock: Man kann die auch einsetzen, um eventuelle Vorteile direkt zunichte zu machen. :mrgreen: