Kann man mit den IBX stabil arbeiten ? - Frage an A.Kosch

[Dietmar Gellner]

Hallo Andreas,
habe schon mehrere Deiner Bücher gelesen, und daraus viel für meine Arbeit mit Delphi entnommen.
Seit einigen Wochen beschäftige ich mich mit dem IB6 und habe auch schon einge Apps. von Paradox in
IB6 konvertiert. Viele Kenner der IB - Komponeten raten mir ab, die IBX zu verwenden, da diese
wohl 'buggy' seien, und nicht stabil arbeiten. Nun möchte ich aber mit diesen Komponeten weiterarbeiten,
da diese zum Lieferumfang von Delphi gehören und die Schnittstellen zu den TDataset's von Delphi
angepasst sind. Da ich weiß, daß Du schon auf Konferenzen zu Fragen der IBX referiert hast, möchte
ich gern zusammengefaßt wissen, was an den IBX noch nicht so funktioniert, an welchen Stellen man
beim Programieren aufpassen muß, was man im Umgang mit Transactionen zu beachten hat und an
welchen Stellen tatsächlich Fehler auftreten und wie man denen begegnen muß.
Das sind zugegebener Maßen viele Fragen. Ich weiß auch daß es Abhandlungen darüber gibt, in denen die
Komponentenpalleten (IBO, IBX) beschrieben und verglichen werden, nur sind diese leider in englischer
Sprache und mein 'engelisch' ist nicht so perfekt !

Vielen Dank
DieGel

[Andreas Kosch]

Hallo,

die IBX-Komponenten stammen formal nicht von Borland, sondern wurden vom InterBase6-Team ins Spiel gebracht. Aus Zeitgründen hat man allerdings die bereits bestehende FreeWare <i>FreeIBComponents</i> lizenziert und weiterentwickelt. Somit gibt es in der Tat einen Unterschied zwischen den BDE-Komponenten (für deren Design sich Borland bei Delphi 1 viel Mühe gegeben hat) und IBX (dessen Fundament "nebenbei" gewachsen ist). An diesem "gewachsenen" Ursprung hat IBX auch heute noch zu knabbern, so dass zur Zeit ein grundlegender Umbau (Speichermodell etc.) im Gespräch ist.

Für die IBX-Komponenten gibt es fast jeden Monat einen neuen Patch (aktuelle Fassung ist die Version 4.3), allein daran erkennt man, dass man bei IBX nicht die gleichen Qualitätsanforderungen wie bei den BDE-/ADO-Komponenten stellen darf. Dies bedeutet jedoch <b>nicht</b>, dass IBX völlig unbrauchbar ist. Fast jedes aktuelle Problem (Bug) lässt sich mit einem Workaround umgegehen (auch wenn das stellenweise nicht elegant aussieht). Wichtig ist nur, dass man im eigenen Projekt jedes (!) Ergebnis einer SQL-Anweisung einmal für alle möglichen Kombinationen von Hand nachprüft (zum Beispiel kann bei einem SELECT immer dann ein falscher Werte zurückgeliefert werden, wenn die Abfrage einen NULL-Wert liefern müsste). Stellt man dann ein Fehlverhalten fest, kann man im konkreten Fall hier im Forum nach einen Workaround fragen. Aufgrund der sehr häufigen IBX-Updates macht es keinen Sinn, eine aktuelle Workaround-Liste zu pflegen, denn die müsste ständig neu geprüft/erweitert werden.

Das Thema Transaktionen ist auch ein Bereich, der sich gravierend von den "bequemen" BDE-Komponenten unterscheidet. Bei IBX muss sich der Entwickler um alles selber kümmern, ein automatischer Wechsel zwischen expliziten und impliziten Transaktionen (BDE: AUTOCOMMIT) ist nicht vorgesehen und wird vom IBX-Mann <i>Jeff Overcash</i> auch nicht empfohlen. Leider ist auch die Dokumentation in den InterBase 6-Handbüchern (PDF-Dateien) stellenweise falsch, da dort das BDE-Verhalten (!?!) beschrieben wird. Für das eigene Projekt bedeutet dies, das man sich vom Design völlig an das C/S-Prinzip ausrichten muss. Ein Commit schliesst die Datenmenge, so dass das Browsen/Editieren/Browsen in einer ständige offenen Datenmenge unmöglich wird - und auch der "Ausweg" CommitRetaining ist aufgrund seiner Nebenwirkungen nur in Sonderfällen sinnvoll.

IBX kapselt das InterBase-API ein, somit fährt man immer dann am besten, wenn man sich auch eng an die Anforderungen des InterBase anlehnt und das Design der Anwendung darauf ausrichtet (die BDE-Komponenten haben im Gegensatz dazu das Ziel, die Unterschiede zwischen den datensatzorientierten Desktop-Datenbanken und den mengenorientierten SQL-Datenbanken auszugleichen).