Problem mit ADO und MS SQL-Server 7

[Stefan Kraus]

Hallo,
ich möchte ein Programm von BDE auf ADO umstellen. Die benutzte Datenbank ist MSSQL 7.
Mein Problem: Ich öffne eine Tabelle mittels ADOTable und will auf den letzten Datensatz. Aber er springt immer auf einen Datensatz im letzten Drittel. Mit BDE funktionierts. Ich habe schon alle möglichen ADO-Parameter (CursorLocation,...) ausprobiert, es kommt immer ein falsches Ergebnis raus. Der Index ist auch richtig gesetzt. Ist das ein Fehler oder was mache ich falsch.
Es soll ein Patch für die ADO-Komponenten geben, aber weder im Entwickler-Magazin (1.2000) noch bei Borland bin ich fündig geworden.
Wer kann helfen?

Danke
Stefan

[Andreas Kosch]

Hallo,

das Patch für ADOExpress wird "inoffiziell" über <b>Code Central</b> bzw. über die Home-Page von Mark Edington vertrieben. Da das schon lange angekündigte UpdatePack#1 immer noch auf sich warten lässt, hat er sich entschlossen, diese unkonventionellen Vertriebswege zu nutzen.

Die neuen Versionen könnten unter http://community.borland.com/homepage (Code Cental-Datenbank) abgerufen werden.

Verstehe ich das Problem richtig? Beim Anklicken auf den TDBNavigator-Button Last springt die DBGrid-Anzeige zwar zum letzten Datensatz, aber die aktuelle Datensatzmarkierung ist in der Mitte der sichtbaren Anzeige? Wenn es sich um dieses Problem handelt, ist mir eine zuständige ADO-Konfigurationsoption schon einmal unter die Augen gekommen (man kann definieren, ob der Cursor am exakten Ende oder in der Mitte der sichtbaren Anzeige stehen soll). Ich muss dann nur noch danach suchen ;-

Auch ich wäre die BDE gerne los geworden. Was ich nicht verstehe an den obigen Kommentaren - genügt es nicht einfach den Login der Komponente TDatabase zu ändern, damit der Connect über einen Alias führt der eben eine ADO ist?<br>Liege ich da falsch?<br>Muss man die TQuery wirklich alle ersetzen - das wäre ja ein Horror

[Andreas Kosch]

Hallo,

sowohl TQuery als auch TTable sind BDE-Komponenten, die mit ADO nicht zusammenarbeiten. Damit keine Illusionen aufkommen - mit einem einfachen Austauschen der Komponenten ist es nicht getan. ADO ist eine völlig andere Philosophie als die BDE, so das in der Regel auch Änderungen am Programm-Design notwendig werden

Wenn das so aufwendig ist frage ich mich welches denn die Gründe sind, die einen solchen Aufwand rechtfertigen?
<br><br>
Gründe die gegen die BDE sprechen sind:<br>
- Installation der BDE und deren Speicherbedarf<br>
- Bei Clients die viele Tage ohne Bootvorgang laufen habe ich mit der BDE Probleme. Diese Programmteile laufen heute über einen direkten Zugriff auf MSSQL APIs. Diese sind jedoch auch nicht so toll.<br>
- Transaktionen mit der BDE unbefriedigend.<br>
- SQL Statements die sehr lange dauern können nicht mit SqlSend abgesetzt werden und auf das Ergebnis gewartet werden.<br><br>

Was raten Sie mir

An welcher Art von Änderung am Design denken Sie da? Es ist ja immer noch ein SQL Interface.
<br><br>
Wenn das so aufwendig ist frage ich mich welches denn die Gründe sind, die einen solchen Aufwand rechtfertigen?
<br><br>
Gründe die gegen die BDE sprechen sind:<br>
- Installation der BDE und deren Speicherbedarf<br>
- Bei Clients die viele Tage ohne Bootvorgang laufen habe ich mit der BDE Probleme. Diese Programmteile laufen heute über einen direkten Zugriff auf MSSQL APIs. Diese sind jedoch auch nicht so toll.<br>
- Transaktionen mit der BDE unbefriedigend.<br>
- SQL Statements die sehr lange dauern können nicht mit SqlSend abgesetzt werden und auf das Ergebnis gewartet werden.<br><br>

Was raten Sie mir

[Andreas Kosch]

Hallo,

oh - für grundlegende Gegenüberstellungen reicht der Platz nicht. Als einziges Beispiel nenne ich den von der BDE her gewohnten <b>Cached Update</b>-Mechanismus. ADO kennt so etwas zwar auch, aber das läuft dort nach völlig anderen Spielregeln ab (Bsp. Fehlerbehandlung bei Update-Konflikten; Master/Detail-Updates etc.).

Die Notwendigkeit für ADO ergibt sich zwangsläufig aus der Festlegung von Microsoft, für den eigenen <b>SQL Server 7</b> nur noch die OLE DB-Treiberverbindung weiterzuentwickeln. Der "alte " DBLib-Treiber bleibt auf dem Stand der Version 6.5. Borland musste für die Enterprise-Version reagieren, um den SQL Server 7 offiziell unterstützen zu können. Also hat man zu ADO als Überbau für OLE DB gegriffen - zumal ADO auch viele andere Datenbankformate unterstützt.

Daher ist der Rat einfach - für alle, die den SQL Server 7 einsetzen, gibt es <b>nur eine</b> Alternative: ADO.

P.S: Wer die Readme zu <I>MS Office 2000</i> durchliest, wird dort eine Info zu JET-Engine (ADO) vorfinden: Immer dann, wenn ADO eine installierte BDE vorfindet, wird diese beim Zugriff auf dBASE- und Paradox-Tabellen auch genutzt. Daher besteht für dBASE- und Paradox-User keine Notwendigkeit zum Umstieg ;-)