oracle ODBC9.2.xxxx funktioniert nicht

[infinitus8]

AdoDataSets mit Server seitigem Cursor funktionieren
nicht mehr mit dem akt. oracle ODBC-Treiber. Hatte
keine Probleme mit der ODBC-Version 8.1.7. Muss ich
etwas an den ODBC-Einstellungen ändern oder abwarten
bis Oracle einen anderen Treiber herausbringt.

[Bernhard Geyer]

Hallo infinitus8,

Melde die Fehler und hoffe. Da Oracle sehr viele Schnittstellen unterstützt (ADO, ODBC, NET8, JDBC, ...) und man nicht genau weiss welche Schnittstelle mit welcher Priorität supportet wird würde ich, wenn es möglich ist, auf die native Net8(9)-Schnittstelle wechseln.
Oder in deiner Programmbeschreibung diese fehlerhaften Treiberversionen als nicht unterstützt beschreiben.

Für Delphi gibt es z.B.

http://www.allroundautomations.nl/ (verwenden wir selbst)

http://www.sqldirect-soft.com

[Vitaliy Polovinkin]

Hallo Bernhard,

so ist es nicht ganz richtig - Oracle DBMS unterstützt direkt nur die Schnittstellen, welche vom TNS-Listener verstanden werden. In diesem Fall wäre es nur SQL*Net/Net8.
ADO und ODBC nur baut auf Net8 auf, ersetzt aber die in keiner Weise (Schichtenmodell). Als Transportprotokoll setzt dann Net8 auf TCP/IP auf etc.

Gruß,
Vitaliy

[Vitaliy Polovinkin]

Hallo infinitus8,

fallst Du benutzt ADO, wozu brauchst Du denn ODBC-Treiber? Nimm doch den nativen OLE-DB Provider von Oracle9i, wird ja auch mitinstalliert. Der Umweg ADO über ODBC war nur aus Übergangsgründen interessant, wo es noch keine reine OLE-DB Treiber gab, ist aber längst obsolet..

[Bernhard Geyer]

Hallo Vitaliy,

unsere Erfahrungen mit Oracle sind (bzw. allgemein mit DB's) das je weniger Protokollschichten dazwischen liegen desto weniger Probleme hat man.

Ein Protokollstack ADO -> ODBC -> TNS-Listener -> DB ist mit Sicherheit fehleranfälliger als ein direkteres aufsetzen wie DOA (www.allroundautomations.nl) -> Net8 -> TNS-Listener -> DB

Auch waren meine Versuche bezüglich OLE-DB-Provider von Oracle auch nicht erfolgreich (ist schon eine Weile her) so das wir bei DOA geblieben sind

[Vitaliy Polovinkin]

Hallo Berhhard,

ich gebe Dir recht, es ist allerdings die Frage der Verhältnismäßigkeit.

Für die wenigsten Problemen & max. Performance - direkt auf Net8 aufsetzen. Ich glaube, wir beide verstehen dabei OCI-Schnittstelle.

Der Aufsatz auf ADO ist zwar nicht so nativ und performant (gerade mit client-based cursors), ist aber wesentlich einfacher bei Implementierung und kompatibler zu anderen DBs..

Ich würde in den meisten Fällen sagen - mittlere Weg - der Zugriff über ADO, aber dafür möglichst wenig Logik auf Client, möglichst viel auf dem Server (mit stored procedures, views und instead-of-triggers auf views).

[Bernhard Geyer]

Hallo Vitaliy,

Die von mir vorgestellten per Link vorgestellten Komponenten haben genauso TDataset-Nachfolger wie ADOExpress. Also ist der Komfort genauso hoch wie bei ADOExpress.<br>
Und wenn man TDataset als "Kompatiblitätschicht" für den DB-Zugriff verwendet genauso DB-Unabhänig wie ADO/ADOExpress.

Es kann schon sein das ich eigentlich die OCI-Anstatt der Net8-Schnittstelle meine (Aber aufgrund der 350 MB-Client-Installation und 40 Startmenueinträge kann man schon mal den Überblick verlieren :-))