IBO-Ablöse

[Norbert Mitteregger]

Ich hab zwar auch schon im D2009 Bereich gepostet aber ohne Erfolg, vielleicht gibt es hier mehr Resonanz.

Leider leider kommen die IBO's für D2009 noch immer nicht und die Hoffnung schwindet von Tag zu Tag (Obwohl es schon lange eine Beta gibt).
Daher wird es mir nicht erspart bleiben die doch sehr lieb gewonnen IB-Objects abzulösen.
Da weiterhin geplant ist, mit Firebird zu arbeiten, glaube ich schon an die Sinnhaftigkeit von Spezialkomponenten wie FIBplus und IBDAC.
Es wurden zwar schon leidenschaftliche Diskussionen zu diesem Thema geführt, aber sie sind doch alle etwas älter und daher meine Frage nach persönlichen Erfahrungen.

Schon mal an alle: Danke

lg Norbert

[Thomas Steinmaurer]

Hallo Norbert,

wir hatten in der Vergangenheit schon gesprochen, tja, leider tut sich bei IBO nur sehr schwer etwas. Es kommt immer wieder mal eine Beta, aber so wirklich die D2009 kompatible Version, im Speziellen Unicode Support, ist so eine Sache ...

Was ist der Weg zu D2009? Rein wegen Unicode?


Die Ablöse muss sich aus meiner Sicht mehrstufig gestalten, weil die Auswahl einer alternativen Connectivity Suite nur ein kleiner Bestandteil ist. FIBPlus ist mit Sicherheit eine gute Wahl. So vermutlich auch andere FB-spezifische Komponenten wie IBDAC. Von Zeos würde ich mit Firebird die Finger lassen. UIB+ ist nett, aber für kommerzielle Entwicklung würde ich auf ein kommerzielles Produkt setzen (FIBPlus, ...). Dann wär dann noch dbExpress mit Third-Party Treibern für < D2010 und einem Embarcadero Treiber in D2010 Enterprise Edition. Allerdings ist die Anwendungsentwicklung in dbExpress doch etwas "anders", wie man sie bis dato gewohnt war, weil man per Default nur Unidirektionale Sets hat und schnell in die ClientDataSet Thematik reinkommt.

Ich denke, in einem ersten Schritt wird es sehr wichtig sein, abzuklopfen, welche IBO Features verwendet werden. Aus dem Kopf heraus:

* TIBO* oder auch TIB_* Komponenten?
* Visuelle TIB_* Komponenten?
* Firebird Events?
* Verteilte Transaktionen (2PC)?
* Addon Komponenten wie TIB_DataPump, TIB_Script, ...?
* DML Caching?
* Automatisches OAT/OIT Management (IBO ist hier ziemlich clever)?
* Und mehr ...

Tja, dann kommt vielleicht auch noch dazu, dass aufgrund des RAD Gedankens von Delphi und der Tatsache, dass die Anwendung über die Jahre gewachsen ist, dass man vielleicht z.B. 10 Query Komponenten mit SELECT * FROM ADRESSE auf unterschiedliche Datenmodule verstreut, vorfindet.

Ich bin selbst in einem Projekt involviert, allerdings mit MSSQL als Backend, wo eine Art Re-Engineering gemacht wird, weil eben über die Jahre der "RAD Gedanke" zu stark verfolgt wurde, d.h. da wieder mal ein Query Objekt, dort wieder eines, usw ...

Das Re-Engineering hat als Ergebnis, dasss ein sauberer Daten-Layer eingeführt wurde, über den die wichtigsten DB-Zugriffe gekapselt sind. Der Daten-Layer soll dann auch als Abstraktionsmittel helfen, um halt bestimmte Daten dann nicht aus der MSSQL-DB, sondern z.B. aus SAP zu lesen. In der Anwendung wird es aber nur ein Objekt TArtikel geben.

Was ich damit sagen will ist, dass man, wenn man schon so einen Schritt in eine andere Connectivity Suite macht, gleich auch etwas weg vom RAD Gedanken geht, hin zu einem sauberen Design mit einem Objektmodell. Leider, am Besten vermutlich als komplette Neuentwicklung.


Thomas

[Norbert Mitteregger]

Hallo Thomas,

ja warum überhaupt D2009?
Naja, ich glaube schon das D7 jetzt schön langsam in die Jahre gekommen ist und wenn ich schon einen Umstieg mache dann doch gleich auf D2009 mit Unicode. Ich hab den Glauben an Delphi nach allen den letzten Jahren noch immer nicht verloren.
Das das für bestehende größere Projekte kaum möglich ist und es meistens sowie zu einer Neuentwicklung führt hab ich auch schon schmerzlich Erfahren müssen. Wobei wenn man sich dann plötzlich wieder mal durch seinen alte Code von vor vielen Jahren arbeitet ist das ganze neu zu programmieren und so machen geistigen Erguss schnell zu ersetzten oft kein Fehler!
Aber alles was jetzt neu gemacht werden muss bzw. diverse kleinere Projekte sollen jetzt gleich mit D2009 realisiert werden.
Bei den neuen Komponenten geht es mir vor allem um Performance, Transaktionshandling und echter Firebird Unterstützung. Visuelle Komponenten hab ich von IBO so gut wie nie verwendet und vielleicht mal ein IB_export als Spezialkompo. Was ich schon gerne verwende sind Events, damit sollten die neuen Komponenten gut umgehen können und vielleicht ein weniger stabiler sein als die IBO's. Solange sie sich mit der Standart TDatasource vertragen sehe ich auch kein Problem mit zusätzlichen Fremdkomponeten. (Reportbuilder, TMS, Devex)
Somit bleiben meiner Meinung nach nur mehr FIBplus und IBDAC übrig.
Daher die Frage nach Erfahrung bzw Punkte die im speziellen gegen oder für ein Produkt sprechen.
Norbert
PS: Ich war der Meinung das IBexpert mit FIBplus programmiert ist und dann sehe ich auch der Homepage das HK-Software auch die IBDAC vertreibt, war auch nicht hilfreich bei der Entscheidungsfindung.

[Markus Kinzler]

Ich arbeite mit IBDAC und bin sehr zufrieden. Für IBDAC spricht die Tatsache, dass obwohl IBDAC 100% native IB/FB-Komponenten sind, der Anbieter ähnliche Lösngen für andere DBMS bietet und neuerdings auch einen DB-unabhängigen Wrapper. Zudem gibt es viele Updates und der Support ist auch gut. FIBPlus scheint aber ein ganz kleines Bisschen schneller zu sein

[Klemmo]

Unterstützung auch von mir für IBDac, hat sich super in diversen D2009 projekten bewährt, haben auch einen super Support. Markus hatte da schon länger einen guten Riecher ;-)

Meine ersten Versuche mit Fibplus unter D2009 hatten teilweise sehr blöde Nebeneffekte, die mögen mittlerweile behoben sein, aber bei neuen Projekten setze ich mittlerweile immer IBDac ein. Es empfiehlt sich aber immer einen Wrapper selbst einzubauen, so das ein späterer Umstieg (warum auch immer) einfacher wird. Das ist aber mit Delphi aufgrund der TDataset Abstraktionsebene ziemlich einfach. Ich habe in der Zwischenzeit einige Kundenprojekte beim Umstieg von IBO, IBX, BDE etc. auf IBDAC mit UTF8 unterstützt und das hat immer erschreckend problemlos geklappt.

Gruß
Holger
www.ibexpert.com

[Norbert Mitteregger]

Danke für eure Informationen,
habe mich jetzt für die IBDAC entschieden und bin sehr zufrieden.
Bin zwar noch im Einarbeiten aber kann sie nur weiter empfehlen.

Grüße aus dem Süden

Norbert
http://www.semmed.at

[Oswald Mair]

Ich habe mich für UniDac entschieden, weil mal mit einer komponente nicht nur Interbase, sondern auch sql-server, mysql ... ansprechen kann und ich bin vollkommen zufrieden, kann ich nur empfehlen.

lg Oswald