Von Paradox nach MS SQL-Server 7.0

[Vergari Marco]

Hallo alle zusammen

Ich habe eine Applikation geschrieben die auf einer Paradox Datenbank aufbaut. Entwicklet habe ich das ganze mit dem C++ Builder 5 Professional. Nun muss ich aus Leistungsgründen und der Komplexität der Datenbank auf einen DB-Server umsteigen. Der Kunde hat bereits einen MS SQL-Server 7.0 im einsatz und wünscht das meine Applikation mit diesem DB-Server auskommt.
Nun habe ich folgende Fragen:<br>
- Geht das mit der Professional Version problemlos oder sollte ich die Enterprise Version besitzten?<br>
- Was muss ich bei der Umstellung der Applikation beachten?<br>
- BDE / ODBC / ADO was ist das beste und was ist ADO genau?<br>
- Ich habe in diesem Forum von vielen Problemen mit MS SQL-Server 7.0 gelesen. Ist es wirklich so schwer, gibt es bessere Lösungen die nicht gleich enorm viel kosten wie Oracle.

Ich weis, es sind etwas viele Fragen, doch ich habe im Umgang mit DB-Server bis heute noch keine Erfahrungen gemacht.<br>
Vielen Dank bereits im voraus.

Gruss<br>
Marco Vergari

[Andreas Kosch]

Hallo,

die Version 7 des Microsoft SQL Servers war der Grund, warum Borland ADO-Komponenten in <i>Delphi 5 Enterprise</i> bereitstellen <b>musste</b>. Denn der alte SQL-Link-Treiber MSSQL ist nur als Notbehelf für die 7er-Version geeignet. Der Grund dafür liegt darin, dass Microsoft die alte <i>DBLib</i>-Schnittstelle nicht mehr unterstützt, sondern nur noch <b>OLE DB-Provider</b> und <b>ODBC</b>-Treiber für den Zugriff auf den Microsoft SQL Server 7/2000 vorsieht. Hinter <b>ADO</b> (ActiveX Database Objects) verbergen sich COM-Objekte, die eine erstaunliche Funktionsbandbreite zur Verfügung stellen und die datenbankneutral eine gemeinsame Programmierschnittstelle anbieten (also so etwas, was auch die BDE mit IDAPI als Ziel hatte).

Für den Zugriff auf die Microsoft ADO-Objekt reicht die Professional-Version von Delphi aus. Allerdings steht dann die Anbindung an TDataSource und somit an TDBEdit/TDBGrid etc. erst dann zur Verfügung, wenn <b>ADO Express</b> als kostenpflichte Komponenten-Sammlung (ca. 400 DM) von Borland nachgekauft wird. Mit dem Upgrade auf die Enterprise-Version ist das nicht notwendig, hier ist (abgesehen von den Patches) alles bereits an Bord.

Das Design der Anwendung muss vermutlich grundlegend geändert werden, um die Anforderungen einer mengenorientierten SQL-Datenbank zu erfüllen. Hier wird das Lesen einschlägiger Bücher zu den Themen Datenbankentwicklung mit Delphi, SQL Server und Datenbankdesign wohl unvermeidlich sein.

Der ODBC-Treiber kommt für uns nicht mehr in Frage, da Delphi nur über die BDE auf ODBC zugreifen kann - aber Borland die BDE offiziell bereits zum alten Eisen gelegt hat. Somit bleibt nur ADO übrig, wobei man entscheiden muss, was wichtiger ist: <br>
a) Bequemlichkeit (visuelle Entwicklung): ADO Express-Komponenten <br>
b) Performance: Native ADO-Objekte (COM-Objekt) ohne Komponenten

Es gibt generell <b>keine</b> Probleme mit dem SQL Server 7/2000, solange sich das Design der Anwendung an die in der Welt der SQL-Datenbanken üblichen Regeln hält und solange der Zugriff über den OLE DB Provider für den SQL Server 7/2000 und somit über ADO läuft. Eine weitere Voraussetzung ist die Installation der folgenden Patches für Delphi 5: <br>
1. Delphi 5 UpdatePack#1 <br>
2. Delphi 5 ADO-Update 1 (Oktober 2000)<br>
3. Delphi 5 ADO-Update 2 (Januar 2001

[Vergari Marco]

Hallo

Danke viel mal für die schnell und sehr ausführliche Antwort.

Sie schreiben immer von Delphi 5, ich nehme an das es mit dem C++ Builder 5 genau dasselbe ist?<br>
Wenn ich mit ADO arbeite, kann ich dann immer noch wie mit einer Paradox Datenbank mit TQuerys, TDBGrid und diesen Komponenten arbeiten oder nicht? Der Unterschied zwischen ADO Express-Komponenten und der Native ADO-Objekte verstehe ich nicht ganz. Wenn ich Die Native ADO-Objekte verwende, kann ich dann auchdie TQuerys brauchen um meine Abfragen zuerstellen oder nicht? Was ist der Unterschied, muss ich ohne Komponenten einfach mehr selber programmieren?

Kennen Sie empfehlenswerte Bücher für den Umgang mit ADO und mit SQL-Servern?

Mfg<br>
Marco Vergari

[Andreas Kosch]

Hallo,

ADO und ADO Express steht auch für den C++ Builder 5 zur Verfügung. Man kann zwischen ADO und ADO Express klare Grenzen ziehen:

a) <b>ADO</b>: COM-Objekte, die in vielen Umgebungen zur Verfügung stehen (Visual C++, Visual Basic, Active Server Pages, Delphi, SQLWindows/32 usw.), aber die keine Verbindungsmöglichkeit zu TDataSet und somit zu den datensensitiven Komponenten von Delphi/C++ Builder haben. Man kann aber allein mit diesen Dingern komplette Anwendungen schreiben (TEdit statt TDBEdit etc.).

b) <b>ADO Express</b>: VCL-Komponenten, die die nativen COM-Objekte von ADO als zur Entwicklungszeit visuell sichtbare Objekte verpacken, die im Objektinspektor konfiguriert werden können. Erst ADO Express stellt die Verbindung zu TDataSet und somit zu den datensensitiven Komponenten von Delphi/C++ Builder her.

Ein unbedingtes Muss ist das folgende Buch: <b>ADO-Programmierung</b> (309 Seiten; ISBN 3-86063-618-9; Microsoft Press). Dort geht es zwar nur um Visual Basic und Active Server Pages, ab das dort gesagt gilt 1:1 auch für Delphi/C++ Builder

[Vergari Marco]

Hallo

Ich habe noch eine kleine Frage.<br>
Sie haben gesagt das wenn man Performance will, besser Native ADO-Objekte und nicht ADO Express-Komponenten einsetzten soll.<br>
Ist der Leistungsverlust bei den Komponenten enorm?<br>
Ich nehme an das der Aufwand ohne Komponenten doch erheblich ist. Lohnt sich das oder nicht?

Vielen Dank für die sehr ausführlichen Antworten.

Mfg<br>
Marco Vergar

[Andreas Kosch]

Hallo,

für den zweitägigen C/S-Kurs der <i>Entwickler Tage 2001</i> habe ich einige Testprogramme für den Performancevergleich beim INSERT, UPDATE oder SELECT vorbereitet.

a) 1000 Datensätze über eine Stored Procedure in eine SQL Server 2000-Datenbank einfügen: <br>
- ADO Express: 1101 Millisekunden <br>
- ADO : 530 Millisekunden

b) 100 Datensätze über eine Stored Procedure aus einer SQL Server 2000-Datenbank auslesen: <br>
- ADO Express: 601 Millisekunden (TADODataSet) <br>
- ADO Express: 230 Millisekunden (TADOStoredProc) <br>
- ADO : 100 Millisekunden (Command-Objekt)

c) 100 Datensätze über UPDATE-SQL-Anweisung in einer SQL Server 2000-Datenbank aktualisieren: <br>
- ADO Express: 220 Millisekunden (TADOCommand) <br>
- ADO : 170 Millisekunden (Command-Objekt)

In einer mehrschichtigen Anwendung (Three-tier-Architektur), bei der sehr viele Benutzer auf einen Application Server zugreifen, macht der Verzicht auf ADO Express durchaus Sinn. In einer "normalen" C/S-Anwendung hängt es davon ab, wieviel Performance-Reserven in der Hardware-Umgebung stecken

[Vergari Marco]

Hallo

Nochmals vielen Dank für die sehr ausführlichen Antworten.

Mfg<br>
Marco Vergar