Aloha

wie euch sicherlich bekannt ist, befinden sich mehrere Fehler in ADODB.pas bei Delphi 4/5/6/7 ... ein Teil wurde wohl in dem Update auf Delphi 7.1 behoben, aber dennoch sind nicht alle ausgebügelt.

Bevor ich jetzt anfange, die komplette Datei umzukrempeln, wollte ich fragen, ob jemand von euch das schon gemacht hat und mir ggf. seine ADODB.pas zur Verfügung stellen könnte.

Mein akutes Problem ist, dass ich bei einer Abfrage in einem AdoDataset einige sehr kuriose Phänomene habe: Field.DataTypes werden sehr bizarr und von Rechner zu Rechner unterschiedlich ausgewertet. Abfrage der RowNum ist mal Number(22), mal Float(0), mal ein Currency...

Wie gesagt... hat da schon jemand eine Lösung für ?

Vielen Dank

C.

Welche Probleme hast Du denn genau?
Und deine geschilderten Probleme hören sich eher unterschieden in der installierten ADO bzw. DB-Teriberversion an. Auf welche DB greift du den zu?

Wir benutzen hier (und bei unseren Kunden) Oracle 7 bis Oracle 10... und es treten immer wieder probleme damit auf... gib einfach mal bei borland quality central ein... da findest du schon Fehlerangaben zu hauf.

Ah. Oracle. Das sagt schon einiges. Der Fehler liegt nicht an Delphi und an der ADODB.pas sondern an Oracle. Je nach Version (und Subversion) werden Datentypen einfach anders gemeldet und behandelt. Ich empfehle dir

1, Schmeiß ADO weg und nimm native Zugriffskomponenten wie ODAC (crlab.com/odac/). Damit hast Du schon mal die Fehlerquellen ADO, ADO-Provider für Oracle und evtl. Oracle-NET-Treiber umgangen

2, Verlagere deinen DB-Zugriff an möglichst eine Unit in deiner Anwendung und verwende wenn möglich keine DB-Sensitiven Controls. Damit kannst Du dann weitere Oracle-Fehler umschiffen.

Wir haben selbst diese beiden Regeln befolgt und haben damit die Probleme mit Oracle (verwenden sonst noch MySQL und MS SQL-Server) auf ein erträglichs Maß reduziert).

Ach ja: Verwendest Du evtl. den ADO-Oracle-Provide von M$. Das wäre noch ein weitere Fehler. Dies ist eine Machbarkeitsstudie und kann keinesfalls für produktive Systeme verwendet werden.

sers
das problem ist an dieser stelle, dass unsere anwendungen von ado und oracle abhängig sind... unsere firma arbeitet seit 10 jahren mit oracle und seit der "ersten" stunde mit ado... bedeutet, dass diese option ausscheidet...

in adodb.pas sind def. einige bugs drin verborgen... einige haben wir schon ausgebügelt (haben unsere adodb.pas bereits angepasst)... aber ich bin dabei, auch die übrigen noch auszumerzen, da borland ja ned aus den pötten kommt

meine frage an dieser stelle war ja nun, ob andere ebenfalls schon bugs behoben haben... (oder bereits alle?) damit ich mir die mühen ned im zweifelsfall umsonst mache...

crowley hat folgendes geschrieben:

das problem ist an dieser stelle, dass unsere anwendungen von ado und oracle abhängig sind... unsere firma arbeitet seit 10 jahren mit oracle und seit der "ersten" stunde mit ado... bedeutet, dass diese option ausscheidet...

Dann bleibt noch die Option ADOExpress zu vermeiden und direkt mit den ADO-Com-Komponenten zu arbeiten. Ich denke aber einige deiner Probleme werden auch hier vorhanden sein. Ich empfehle deshalb mit nativen Komponenten zu arbeiten da man hier erfahrungsgemäß weniger Probleme hat. Aber wenn ihr auf der ADO-Schiene weiter Probleme beseitigen wollte die man andersweitig nicht habt, bitte. Bei korrekter Kapslung der DB-Schnittstelle bzw. der Datenbankabhänigkeiten auf wenige, im Idealfall auf eine Unit ist solch ein Wechsel in wenigen Tagen geschehen. Hab selbst sowas schon beim wechsel des Zugriffs auf MySQL durchgeführt.

crowley hat folgendes geschrieben:

in adodb.pas sind def. einige bugs drin verborgen... einige haben wir schon ausgebügelt (haben unsere adodb.pas bereits angepasst)... aber ich bin dabei, auch die übrigen noch auszumerzen, da borland ja ned aus den pötten kommt

Das keine Vorhanden sind habe ich auch nicht behaubtet. Habe selbst 2 Stück in Bereich Unicode behoben.

crowley hat folgendes geschrieben:

meine frage an dieser stelle war ja nun, ob andere ebenfalls schon bugs behoben haben... (oder bereits alle?) damit ich mir die mühen ned im zweifelsfall umsonst mache...

Diese beiden Fixes könnte ich dir geben. Wird vermutlich aber nichts bringen da AFAIK Oracle unter Win32 keine native Bereitstellung der Daten als WideString bietet.

Wie steht's denn mit der Verwendung von TBetterADODataset...?

Hi.

Zitat:

Ach ja: Verwendest Du evtl. den ADO-Oracle-Provide von M$. Das wäre noch ein weitere Fehler. Dies ist eine Machbarkeitsstudie und kann keinesfalls für produktive Systeme verwendet werden.

Kann mir jemand sagen wo man einen brauchbaren ADO-Oracle-Provider findet?
Mit dem "normalen" Standard-Client von Oracle wird meines Wissens nach kein ADO-Provider ausgeliefert.

Vielen Dank im vorraus!

Joschi