DBExpress?

[Stephan Schneider]

Hallo,

wer kann mir etwas über DBExpress erzählen? Ist die Verwendung dieser Zugriffsschicht zu empfehlen? Funktioniert sie mit aktuellen SQL-Servern (Oracle 9i, 10g; MS SQL 200, 2005; usw.)

Mir geht es bei der Beantwortung der Frage ausschließlich um DBExpress!

Danke
Stephan

[Bernhard Geyer]

Kommt darauf an ob du Geld ausgeben willst oder nicht:

Die von Borland gelieferten DBExpress-Komponenten sind teilweise hoffnungslos veraltet. Willst Du wirklich auch aktuelle Versionen unterstützen so wird dir nichts anderes übrig bleiben als dir Komponenten von 3th-Party-Herstellern zu kaufen (z.B. von Core Labs).

Wieso willst Du denn DBExpress einsetzen. Wenn du mehrere DB's unterstützen willst kannst du auch bei TDataset-Basierenden Komponenten bleiben und mittels Bridge-Pattern den DB-Zugriff kapseln

[Stephan Schneider]

Hi Bernhard,

Danke für Deine wie immer kompetente Antwort. DBExpress war nur noch ein theoretischer Themenkomplex, der Beachtung bei unserer BDE-Umstellung gefunden hat.

Mittlerweile hat man sich entschieden, ADO zu verwenden. Einfach die alten BDE-Zugriffskomponenten raus, ADO rein. So einfach soll's gehen. Eine Restrukturierung mittels Bridge-Pattern würde zu aufwendig sein. Und ADO erfüllt ja auch das Kriterium der Datenbankunabhängigkeit...so die Aussagen der externen Berater

[Bernhard Geyer]

> Mittlerweile hat man sich entschieden, ADO zu verwenden. Einfach die alten BDE-Zugriffskomponenten raus, ADO rein. So einfach soll's gehen.

Theoretisch - Ja. Die Probleme liegen aber im Detail verborgen.

> Eine Restrukturierung mittels Bridge-Pattern würde zu aufwendig sein.

Sagst wer? Wir selbst haben auch das Bridge-Pattern und unterstützen 4 DBMS-Systeme. Erstens ist der DB-Spezifische Code auf ca. 4-5 Tausend Zeilen Code beschränkt und zweitens habe ich schon mal einen Ersatz einer zugekaufen DB-Zugriffskomponente in 1 Tag durchgeführt.

> Und ADO erfüllt ja auch das Kriterium der Datenbankunabhängigkeit...so die Aussagen der externen Berater.

Dann frag ihn mal wie er folgende Dinge DB-Unabhängig gestalten will:

- Unicode-Support
- Top/Limit-Unterstützung
- Blobs
- Unterschiede in der SELECT-Syntax
- SQL-Code zur Erzeugung der Datenbank

Und falls er auch noch den MS SQL-Provider für Oracle einsetzen will dann vermute ich mal das der Berater ein vollkommener Theoret ist und sein Geld nicht wert ist

[Stephan Schneider]

Das Unschöne an der Sache ist, dass es im Hinblick auf Datenbanken neue Anforderungen gegeben hat. War man früher der Meinung nur Oracle und MS SQL bedienen zu müssen, so stehen neuerdings Systeme wie MySQL und PostgreSQL auf dem Plan. Und das alles mit ADO.

Ich selbst wäre für eine Umstellung gem. Bridge-Pattern gewesen. Die Anwendung muss noch jahrelang (>= 4 Jahre) arbeiten und die genannten Server unterstützen. Und in Anbetracht der aktuellen Probleme mit der BDE darf es absolut keine zukünftigen Probleme mehr mit den Serverzugriffen geben. Deshalb war mein uneingeschränkter Rat eine architektonische Restrukturierung, jeden DB-Zugriff eigens kanalisieren und die Daten in nicht-datensensitiven Controls darstellen. Natürlich wäre das ein großer Aufwand gewesen, aber man wäre auch auf der sicheren Seite im Hinblick auf echte DB-Unabhängigkeit.

Die hinzugezogenen Berater waren der Auffassung, eine Lösung mit ADO ist absolut zukunftssicher. Kein Problem mit OLE-DB-Providern, kein Problem mit den genannten Servern

[Bernhard Geyer]

> War man früher der Meinung nur Oracle und MS SQL bedienen zu müssen, so stehen neuerdings Systeme wie MySQL und PostgreSQL auf dem Plan. Und das alles mit ADO.

Viel spaß wenn ihr wirklich ADO wollt. Gibt es denn für MySQl und PostgreSQL brauchbare ADO-Treiber? Oder geht mann dann noch über ODBC.

> Die hinzugezogenen Berater waren der Auffassung, eine Lösung mit ADO ist absolut zukunftssicher.

Nachdem MS seit 2002 alles auf .NET Focusiert und damit alle Win32-Entwicklung mehr oder minder verringert denke ich nicht das MS im Bereich ADO noch mehr als Bugfixes betreiben wird.

> Kein Problem mit OLE-DB-Providern, kein Problem mit den genannten Servern.

Nagel den Breater fest. Frage ihn wie er sich sowas erklärt:

<a href="http://www.delphipraxis.net/topic95769_adofunktion+beendet+nicht.html">ADO-Funktion beendet nicht </a><a href="http://www.delphipraxis.net/topic94333_ado+sql+string+laengenbegrenzung.html>
<a href="http://www.delphipraxis.net/topic81722_kein+zugriff+auf+oracle+stored+proc+mit +resultset.html">Kein Zugriff auf Oracle Stored Proc mit Resultset </a>
<a href="http://www.delphipraxis.net/topic58745_ado+mit+oracle+provider+nicht+gefunden. html">ADO mit Oracle: Provider nicht gefunden</a>

Die Liste kann beliebig verlängert werden. Am besten stellst Du deinen Berater ein Beispielprojekt mit eines dieser Problem vor und läßt es ihm lösen.

Ausssagen wie "kein Problem ..." deuten wieder mal sehr deutlich auf einen Powerpoint-Berater ohne viel praktischer Erfahrung

[Falk Prüfer]

<cite>Ausssagen wie "kein Problem ..." deuten wieder mal sehr deutlich auf einen Powerpoint-Berater ohne viel praktischer Erfahrung.</cite>
Und der Entwickler ist anschließend der zweimal Doofe, weil er 1. die "nichtvorhandenen Probleme" an der Backe hat und 2. in den Augen seines Chefs unfähig ist, so eine "simple" Umstellung auf die Reihe zu bringen, während der "tolle" Berater seine Kohle eingestrichen hat und bereits dem nächsten Kunden das Blaue vom Himmel lügt (

Ich versteh nicht, warum man immer auf die Leute mit den tollen Präsentationen auf den tollen Laptops hört, statt auf die die täglich die Arbeit machen *kannmannurmitdemkopfschütteln*

Sorry, ist wenig produktiv mußte ich hier aber mal loswerden ;

[Bernhard Geyer]

> Sorry, ist wenig produktiv mußte ich hier aber mal loswerden

Wieso? Dann merkt Stephan das ich nicht alleine diese Meinung habe.

Hab übrigens mal meinen Job gewechselt als solche "Profis" in einem Projekt das sagen hatten und meines erachtens fast gar nichts mehr ging

[Stephan Schneider]

Danke für Eure rege Beteiligung.

Ich selbst sehe das eher gelassen, da ich mit der Umsetzung wahrscheinlich ohnehin nicht allzuviel zu tun haben werde. Wenn wieder Probleme auftauchen sollten, dann muss ich dafür nicht meinen Kopf hinhalten.

Ich hatte auch nicht den Eindruck, dass es sich bei den beiden Experten um Powerpoint-Berater handelt. Ganz im Gegenteil. Einer der Experten ist sogar in diesem Forum sehr aktiv ;-)

Mich hat nur die von beiden Leute getroffene Aussage, man wäre mit ADO auf der absolut sicheren Seite, etwas irritiert. Erfahrungsgemäß, so auch die Aussagen der beiden, gibt es mit ADO keinerlei Probleme: Oracle oder MS SQL-Server? Passende Ole-DB-Provider sind vorhanden. MySQL, PostgreSQL? Her damit, mit ADO kein Problem.

Ich stimme auch aufgrund einer anderen Diskussion mit Bernhard überein, dass es wesentlich sinnvoller gewesen wäre, die Anwendung architektonisch zu restrukturieren (-> Bridge-Pattern). Dann wäre man de facto DB-unabhängig

[Bernhard Geyer]

> Ich selbst sehe das eher gelassen, ... dann muss ich dafür nicht meinen Kopf hinhalten.

Und willst evtl. deine Arbeitskollegen ins Messer laufen lassen?

> Ganz im Gegenteil. Einer der Experten ist sogar in diesem Forum sehr aktiv ;-)

Bei ADO würde mir da nur einen einfallen. Jedoch hat dieser AFAIK nur praktische Erfahrungen mit MS SQL-Server und Access. Und ob er wirklich die Probleme mit anderen DB's abschätzen kann ...

> Ich stimme auch aufgrund einer anderen Diskussion mit Bernhard überein, dass es wesentlich sinnvoller gewesen wäre, die Anwendung architektonisch zu restrukturieren (-> Bridge-Pattern). Dann wäre man de facto DB-unabhängig.

Ihr habt doch noch nicht die Umstellung angefangen? Je nachdem wie die SW aufgebaut ist sollte das doch möglich sein ohne alles zu verändern das Bridge-Pattern schrittweise einzuführen. Wenn der DB-Layer aber eh überall "reinreicht" so ist es fraglich ob ihr wirklich dann noch eine wartbare SW habt wenn ihr überall eure SQL-Statements DB-Spezifisch zusammenbaut und nach und nach mehr probleme habt wenn ihr zusätzliche DB's unterstützen wollt

[Stephan Schneider]

Keine Sorge, es trifft keine anderen Kollegen. Dieser Teil wird soz. "outgesourct". Der Berater steht zugleich für ein Unternehmen, das diese Umsetzung durchführen kann. Und natürlich ist es klar, dass das Unternehmen, das den Zuschlag erhält, auch dafür verantwortlich ist

[Bernhard Geyer]

Ach so. Das Programm soll dann von externer Firma bis zum lebensende weiterentwickelt werden. Falls die mit ADO zurecht kommen - OK. Mußt nur mit dieser Lösung damit leben das ihr immer entsprechende Treiber installieren müßt

[Stephan Schneider]

Ja, im Prinzip ist es so. Ersetze lebenslang durch 4 bis 5 Jahre und es trifft den Sachverhalt noch genauer.

Es ändert aber nichts an der Tatsache, dass es mit ADO wahrscheinlich nicht so reibungslos ablaufen wird, wie vermutet. Das zumindest hat mir auch unsere Diskussion gezeigt. Interessant wird die ganze Sache erst dann, wenn Probleme auftauchen.

Im Zusammenhang mit der BDE wurde auch von vielen Seiten gesagt, dass es prinzipiell mit den Oracle Versionen 9 bzw. 10 gehen sollte. Solange keine proprietären Features der höherversionierten Varianten verwendet werden, dürfte es doch keine Schwierigkeiten geben. So zumindest die graue Theorie. In der Praxis habe ich es nicht geschafft, dass System reibungslos mit Oracle ans Laufen zu bringen. Ich benutze keine obskuren Komponenten, sondern die Delphi 6 eigenen TTable und TQuery Komponenten. Alle Attribute innerhalb der DB-Tabellen sind allesamt elementaren Datentyps, sprich Integer, Smallint, Varchar(x) usw. Kein einziges Blob-Feld oder ähnlich "exotisches". Die Queries selbst bestehen zum Großteil aus ein einfachen Selects mit obligatorischen Where-Clauses. That's it. Eigentlich nichts Außergewöhnliches. Und trotzdem überrede ich die liebe BDE nicht, mit Oracle 9i oder 10g zusammenzuarbeiten. Und das ist dann der oft zitierte Unterschied zwischen Theorie und Praxis

[Bernhard Geyer]

> Interessant wird die ganze Sache erst dann, wenn Probleme auftauchen.

Wenn es externe Programmierung ist so müßt Ihr den Vertrag passend gestalten so das ihr nicht der Dumme seit. Also u.U. Rechtsanwälte die Ahnung von SW-Entwicklung haben beauftragen.

> Im Zusammenhang mit der BDE wurde auch von vielen Seiten gesagt, dass es prinzipiell mit den Oracle Versionen 9 bzw. 10 gehen sollte.

Da Oracle massive beim Welchsel von Version 9->10 die Net-Clientschnittstelle geändert hat würde mich das überraschen. Mußten auch bei unseren native Komponenten auf eine neue Version wechseln um damit zurecht zu kommen

> Alle Attribute innerhalb der DB-Tabellen sind allesamt elementaren Datentyps, sprich Integer, Smallint, Varchar(x)

Darft nur nicht eine Kombination von Oracle-Server-Version und Client erwischen bei denen es schon auf Oracle-Seite nicht geht