Probleme mit TADOQuery wenn zuviele Spalten?

[Jumpy]

Hallo,

ich habe in Delphi6 eine Anwendung erstellt, mit der man auf unsere DB zugreifen kann.
Jetzt hat sich gezeigt, dass es bei einer einzigen Tabelle Probleme gibt.

Die aussagekräftige Fehlermeldung lautet: Unbekannter Fehler!

Die Tabelle ist recht breit, ca. 170 Spalten. Vllt. liegt es daran?

Habe zum Testen ein Mini-Projekt gebaut: DBGrid-TDataSource-TADOQuery
(Rechner mit XP, 32bit)

Ist das Select-Statement auf einige Spalten beschränkt, klappt es:
Select Sp1, Sp2 From Tabellenname

Will ich aber alle Spalten haben, kommt diese tolle Fehlermeldung.
Select * From Tabellenname


Habe dann das Mini-Projekt auf unserer VM (Win7, 64bit) in Delphi2010 nachgebaut, SQL-Statements funktionieren hier beide! Keine Fehlermeldung.

Ich vermute, dass es irgendwie an der ADO-Komponente liegt. Ist die in D6 anderes als in D10? Was könnte es noch sein? Könnte es auch am Rechner liegen?


Edit: Noch als ich obiges geschriben habe, ist mit eingefallen, dass ich die Frage, ob es am Rechner liegt selber klären kann. Habe beide exe, die von D6 und die von D10 erzeugte, auf meinem armen kleinen alten XP Rechner laufen lassen. Bei beiden kam die Fehlermeldung. Bei exe funktionieren aber in der Win7-VM problemlos und auch mein ursprüngliches Programm läuft da fehlerfrei.
Fragt sich nur, was kann es genau sein? (Obwohl die VM 64 bit ist, wird doch mit 32 bit Treibern gearbeitet, soweit ich weiß).

[shmia]

Hast du mal geschaut, was in der Errors Collections drinsteht?
http://www.delphipraxis.net/24671-ad...-anzeigen.html

[jobo]

Schau Dir auch mal die Feldtypen an.
Nicht alles was mit irgendeinem anderen Treiber reingekommen ist, kommt mit ADO wieder raus. Übliche Verdächtige sind z.B. Datumsfelder mit sehr großen/kleinen Werten.
Ich würd zur groben Prüfung mal ein Select bauen mit allen Spalten außer Date Spalten.

Welcher Oracle Treiber? Der von Oracle oder der von MS oder .. ?

[Bernhard Geyer]

Zitat von jobo:

Welcher Oracle Treiber? Der von Oracle oder der von MS oder .. ?

Der von MS ist schrott und seit 1/2 endlich offziell von MS abgekündigt.

Für Oracle-Zugriff würde ich eh den direkten Zugriff verwenden wie ihn Devart bietet.

[Jumpy]

@shmia:
Werde ich morgen auf der Arbeit mal ausprobieren, wußte nicht das sowas geht. e.message war alles was ich bisher kannte

@jobo:
Feldtypen kann ich auch mal gucken. Ist bei 170 Feldern aber ein Angang. Komisch aber das es bei einer Maschine funzt, bei der anderen aber nicht.

Treiber natürlich von Oracle, wobei auf dem Rechner, wo es funzt ist 11g drauf, auf dem wo es nicht geht irgendwas mit Ora92 (ist das dann 9i oder so). Könnte natürlich ein Grund sein, warum es mal geht, mal nicht.

Zitat von Bernhard Geyer:

Für Oracle-Zugriff würde ich eh den direkten Zugriff verwenden wie ihn Devart bietet.

Was ist denn direkter Zugriff? Ich bin ja schon froh, dass ich ADO benutzen soll und nicht die BDE (was man so hört).

@all: Danke schon mal für die Anregungen. Werd morgen mal weiter dran rumtüffteln.

[Bernhard Geyer]

Zitat von Jumpy:

Treiber natürlich von Oracle, wobei auf dem Rechner, wo es funzt ist 11g drauf, auf dem wo es nicht geht irgendwas mit Ora92 (ist das dann 9i oder so). Könnte natürlich ein Grund sein, warum es mal geht, mal nicht.

Das ist sehr wahrscheinlich der Grund. Deshalb ist es so problematisch sich auf soche Treiber zu verlassen. Bei MS kann man wenigstens davon ausgehen das die Windows-Updates dafür sorgen das fast alle Rechner ähnlich aktuellen Treiberstand haben.

Zitat von Bernhard Geyer:

Was ist denn direkter Zugriff? Ich bin ja schon froh, dass ich ADO benutzen soll und nicht die BDE (was man so hört).

Direkter Zugriff = Keine (evtl. Fehlerhafte) Zwischenschicht:

Aktueller Weg:

Anwendung -> ADOExpress -> ADO -> OLE DB Provider von Oracle -> NETx-Treiber -> DB

Direkter Weg

Anwendung -> DevArt-Kompos -> DB

bzw. falls man auf den Net-Provider aufsetzen will

Anwendung -> DevArt-Kompos -> NETx-Treiber -> DB

Wo weren sich wohl vermutlich wenige Fehler verstecken?