BDE oder DBexpress

[Volkmar Rigo]

hallo...<p>
... noch mal ein oft diskutiertes thema:<P>
sollte man neue application (verwaltungssoftware) mit dbx machen oder bei der bde bleiben. meine anforderungen sind:<P>
client/server (möglicherweise midas)<br>
interbase (innerhalb des nächsten jahres vermutlich auch oracle)<br>
performance (ist immer gut)<BR>
möglichst einfache installation<P>
ich hab gelesen, daß oracle im moment vom speed her noch nicht optimal ist (weil die einstellung Rowset Size = 0 nicht geändert werden kann), aber das soll besser werden.<br>hat jemand erfahrungen oder empfehlungen. ich tendiere im moment, dbx zu verwenden.<p>
grüße<p>
volkmar

[Andreas Kosch]

Hallo,

wenn Performance im Mittelpunkt steht, ist dbExpress gegenüber der BDE und IBX die schlechteste (langsamste) Lösung, wenn eine InterBase-Datenbank dranhängt. Technisch gesehen ist jedes dbExpress-Programm eine dreischichtige Anwendung (Three-tier), auch wenn 2 Schichten davon in einer EXE liegen. Da im Hintergrund immer MIDAS (alias DataSnap) im Spiel ist, unterliegt die Anwendung auch dem Prinzip des kleinsten gemeinsamen Nenners aller verwendbaren Datenbanken.

Die BDE ist heute aber auch keine zukunftsfähige Lösung mehr, denn bei der Treiberanbindung wird wohl der heutige Stand eingefroren

[Volkmar Rigo]

hallo,<P>
praktisch ist das sqlclientdataset nicht das schnellste. ich hab aber eh vor, eine appliaction nach dem muster der oop-artikels von holger klemt zu erstellen. also komme ich bei den standardaktionen one das sqlclientdataset. nur bei reports und grids brauche ich das ding.<p>
mein problem ist, daß ich auf ado nicht wechseln kann, da interbase im moment meine hauptdatenbank ist. ibx kann ich nicht nehmen, da ich dann mit oracle probleme kriege, da ich dann meine ganzen klassen mit 2 komponentensets aufbauen muss (was ich nicht will).<br>
ist dbx bei allem langsamer oder nur bei massenoperationen (die man ja eh nach möglichkeit vermeiden soll)?<P>
grüße<br>
volkma

[Andreas Kosch]

Hallo,

wenn man auf "klassische" Art und Weise C/S-Anwendungen schreibt und jede SQL (SELECT, INSERT, UPDATE, DELETE) einzeln zum InterBase schickt, sollte dbExpress ein gleichwertiger Ersatz für IBX sein. Allerdings gehen dann die RAD-Vorteile (Rapid Application Development) von Delphi weitgehend verloren. Wenn es aber feststehende Faktoren (InterBase + ORACLE) gibt, muss man Kompromisse eingehen

[Ralf Loga]

Hallo Hallo,<br>
ja, ja der Holger.<br>
Ich hatte mich schon einmal einen lieben langen Tag mit Ihm über<br>
das oop-Konzept ("positiv") gestritten.<br>

Alles hat seine Vor - und Nachteile.<br>

Die gewonnen Einsichten jetzt hier darzustellen würde etwas zu weit führen.<br>

Ich arbeite zur Zeit schon mit den dbExpress Komponenten in Kombination mit Provider/ClientDataSets bzw. mit dem SQLClientDataSet.<br>

Wenn ein ClientDataSet einen oder mehrere Datensätze mit ApplyUpdates <br>
zum Server schickt werden über die Komponente TSQLResolver sowieso<br>
einzelne INSERT, UPDATE, DELETE Statements erzeugt.<br>

Wenn die Datenmenge auf dem Client begrenzt werden soll kann zusätzlich<br>
die Eigenschaft Packetrecords,z.B. auf 20, gesetzt werden.<br>
Über diese Kombination können wieder alle datensensitiven Komponenten<br>
verbunden werden.

Bis dann
Ral

[Michael Ebner]

Ich habe gerade fünf Möglichkeiten durchgemessen, auf InterBase zuzugreifen:

1. BDE
2. IBX
3. dbExpress
4. FIBlus
5. IBObjects

Fazit:

IBObjects vergessen wir ganz schnell wieder.

Bei der BDE schlägt sich TQuery ganz wacker, und dass TTable nicht erste Wahl ist, hat sich wohl inzwischen herumgesprochen.

FIBPlus und IBX sind aus Sicht der Performance in etwa gleichwertig, mal hat IBX die Nase vorne, mal FIBPlus.

Bei dbExpress hängt es deutlich vom Einsatzzweck ab. Bei Anwendungen, die einfach nur alle Datenätze fetchen (Listendruck), hat dbExpress die Nase vorne, und auch dort, wo auf die Annehmlichkeiten von DBGrid verzichtet werden kann.

Dort, wo die Datensätze gepuffert werden müssen, kann dbExpress nur dann in der "Spitzenliga" mitspielen, wenn man mittels PacketRecords nicht alle Datensätze fetcht.

Daß dbExpress die langsamste Lösung ist, kann man so nicht verallgemeinern

[Peter Adrian]

Hallo Michal<BR><BR>
> IBObjects vergessen wir ganz schnell wieder. <BR><BR>
Warum ? <BR><BR>
Gruß Pete

[HUK]

Datenbankzugriff remote mit dbexpress

Hallo

sehe ich das richtig?

DBExpress von Borland Borland Studio 2006

ist NICHT in der Lage eine Datenbankverbindung, für eine Datenbank welche
remote ist, herzustellen?

[Bernhard Geyer]

> sehe ich das richtig?

Nein. Das siehst du falsch. Die dbExpress-Treiber werden lizenztechnisch bei der Pro-Version auf lokalen Zugriff beschränkt. Erst die Enterprise-Version gibt den Remote-Zugriff frei.

Aber wenn man nicht so viel Geld für die Enterprise-Version ausgeben will: Es gibt ja Komponentenhersteller die solche Beschränkung nicht haben und viel weniger Kosten als Mehrkosten Pro <-> Enterprise.

[Markus Kinzler]

-Zeos
-MDO
-ODBC
-ADO
und mein Tipp (wenns ein bisschen Kosten darf) IBDAC von Core Labs

[Bernhard Geyer]

> und mein Tipp (wenns ein bisschen Kosten darf) IBDAC von Core Labs
Hab ich auch - für MySQL - Erste Sahne. Nichts ist schneller!

[HUK]

Hallo Bernhard, guten Tag!

Das ist ja interessant.

Ich habe die Enterprise version. Es Steht auf der Schachtel, auf den CD's
und bezahlt habe ich sie auch.

Nur eine Möglichkeit eine Datenbank welche Remote ist sehe ich nicht.
DB ist bei mir
a) DB2
b) MSSQL
c) MySQL
d) SQLite3

Muss dies evtl. über BDS\4.0\dbExpress\dbxconnections.ini geschehen ?

Gruss Uli

[Bernhard Geyer]

Frag mich bitte keine Details. Hab um dbExpress immer einen großen Bogen gemacht. Aber die Enterprise-Version kann es (alles andere wäre nicht zu verstehen).