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:

Zitat von jobo (Beitrag 1097242)

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 :oops:

@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:

Zitat von Bernhard Geyer (Beitrag 1097253)

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:

Zitat von Jumpy (Beitrag 1097280)

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:

Zitat von Bernhard Geyer (Beitrag 1097253)

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?

[Jumpy]

Hallo, mal ein Update zur Lage der Nation...

Zitat:

Zitat von Bernhard Geyer (Beitrag 1097285)

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

Ich benutze mit ODBC ja glaub ich noch eine Schicht mehr, oder zumindest einen anderen Provider. Hab mir nochmal den Connection-String angeschaut, da ist der Provider MSDASQL.1 (MS OLE DB Provider for ODBC Drivers). Dann noch der ODBC-Treiber als weitere Schicht?

Hab nun testweise mal auf ODBC verzichtet und benutze nun direkt den Oracle Provider for OLE DB und gehe damit direkt an die Datenbank und siehe da, es geht.
D.h. es scheint wirklich am ODBC-Treiber zu liegen, dass es mal geht (neuer Treiber) und mal nicht (alter Treiber).

Desweiteren habe ich auch durch mühevolles rumraten herausgefunden, dass nicht, wie zunächst vermutet, die "Breite" der Tabelle schuld ist, sondern ein Datenfeld vom Typ Long. Habe daraufhin weitere Tabellen mit Long-Datentypen gefunden, die auch Ärger machen. Leider können wir daran nichts ändern.
Ach ja, die Einstellung "Force Long retrival" oder so ähnl., die man dem ODBC-Treiber mitgeben kann, hat auch nicht geholfen.

Über kurz oder lang werden wir also wohl auf neue ODBC_Treiber wechseln müssen (da wir sowieso bald neuere Oracle Clients brauchen, kommt das sowieso irgendwann).
Nochbesser wäre wie du gesagt hast, sicher der native Zugriff, aber dazu muss noch viel Überzeugungsarbeit geleistet werden.

Danke, aber auf jeden Fall für die Tips

[Bernhard Geyer]

Zitat:

Zitat von Jumpy (Beitrag 1098222)

..., da ist der Provider MSDASQL.1 (MS OLE DB Provider for ODBC Drivers).

Über kurz oder lang werden wir also wohl auf neue ODBC_Treiber wechseln müssen (da wir sowieso bald neuere Oracle Clients brauchen, kommt das sowieso irgendwann).

Der obige Eintrag weist auf einen MS-Treiber hin. Und dieser wird nicht aktualisiert wenn man den Oracle-Client aktualisiert.
Da MS diesen abgekündigt hat wird diese über kurz oder lang gar nicht mehr ausgeliefert, sprich: Dein Programm startet gar nicht mehr.

[jobo]

Zitat:

..LONG.. leider können wir daran nichts ändern..

Da hilft Dir vermutlich mittelfristi auch ein toller Third Party Treiber nicht unbedingt weiter. LONG soll nicht mehr verwendet werden, der Typ wird nur noch aus Kompatibilitätsgründen unterstützt.

LOB ist angesagt.

[Jumpy]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1098224)

Zitat:

Zitat von Jumpy (Beitrag 1098222)

..., da ist der Provider MSDASQL.1 (MS OLE DB Provider for ODBC Drivers).

Über kurz oder lang werden wir also wohl auf neue ODBC_Treiber wechseln müssen (da wir sowieso bald neuere Oracle Clients brauchen, kommt das sowieso irgendwann).

Der obige Eintrag weist auf einen MS-Treiber hin. Und dieser wird nicht aktualisiert wenn man den Oracle-Client aktualisiert.
Da MS diesen abgekündigt hat wird diese über kurz oder lang gar nicht mehr ausgeliefert, sprich: Dein Programm startet gar nicht mehr.

"MS OLE DB Provider for ODBC Drivers", so hab ich das verstanden, ist das MS-Ding, um ODBC-Datenquellen ansusprechen. "Ding" weil ich nicht weiß, was es wirklich ist, beim Erstellen einer Connection hab ich es unter dem Punkt Provider ausgewählt.

Es ist aber nicht der ODBC-Treiber, sondern wie gesagt der Provider für den Treiber, oder so?

In unserer modernen Maschiene wird (zumindest dem Namen nach) der selber Provider benutzt und da funktioniert es ja. Das einzige was da anders ist, ist halt der ODBC-Treiber, der dann von diesem Provider angesprochen/benutzt wird.

Ich gehe daher schon davon aus, das ein Oracle-Client-Wechsel zusammen mit einem ODBC-Treiber-Wechsel das Problem zumindest kurzfristig löst.

In allen anderen Punkten habt ihr natürlich recht, das das alles nicht das Wahre ist, aber diese Entscheidungen liegen über meiner Gehaltsstufe (wie eigentlich alles, da ich ja nur der Azubi bin ;-) ).

@jobo: s.o. Hinzukommt noch, dass die DB eigentlich zu einer Fremdsoftware gehört, die halt aus welchen Gründen auch immer noch Long-Datentypen benutzt. Das ist öfters schon bemängelt worden, aber ich glaube die Hersteller trauen sich da nicht so ran. Wahrsch. weil keiner weiß, wo es lles knallt, wenn man da mal was ändert. Stichwort Software-Evolution.

[Bernhard Geyer]

Zitat:

Zitat von Jumpy (Beitrag 1098254)

"MS OLE DB Provider for ODBC Drivers", so hab ich das verstanden, ist das MS-Ding, um ODBC-Datenquellen ansusprechen.

Vergiss das letzte was ich gesagt habe. Habe es mit dem "MS Oracle Provider" verwechselt.

[Jumpy]

OK. Stimmt ja der ist wirklich Mist.
Hoffe MS hat das jetzt nicht gehört:oops:

[jobo]

Wenn Du mit ADO via OLEDB Provider for ODBC arbeitest, ist das schon recht "umständlich", dann noch veraltete Feldtypen. Da kann man nicht viel erwarten.
Welche Clientversion von Oracle wird denn derzeit eingesetzt?
Wenn es eine ältere ist, würde ich eher den ADO OLEDB Provider von MS empfehlen.
Wenn es eine neuere ist, sagen wir ab 9 oder 10 eher den Provider von Oracle.
LOBS sind allerdings nach meiner Erfahrung kein Aushängeschild des MS Treibers gewesen, dann lieber Oracle.

Zum eigentlichen Problem:
LONG ist ja per se eher selten (max ein Feld pro Tabelle?). Also einfach sparsam verwenden. :)
Es dürfte sowieso keine Anwendung geben, die Felder bis 2Gb Größe im Normalbetrieb bis ins GUI schleppt. Wenn dann nur auf Anforderung und das kann man ja dann gezielt per Stored Proc regeln, solange man nicht migrieren kann/darf.

P.S.: Eine Stored Proc, die beim Lesen/Schreiben von/nach Long in CLOB konvertiert, geht wohl doch nicht, zumindest hab ich im Nachhinein keine CLOB to LONG Konvertierung gefunden, was ich eigentlich für selbstverständlich hielt.
Zur Entschuldigung sei gesagt, das LONG schon seit Oracle 8 verboten ist, und da war ich noch klein. ;)

[Jumpy]

Zitat:

Zitat von jobo (Beitrag 1098460)

Wenn Du mit ADO via OLEDB Provider for ODBC arbeitest, ist das schon recht "umständlich", dann noch veraltete Feldtypen. Da kann man nicht viel erwarten.

Ich weiß, aber das zu Ändern müssen andere Entscheiden. Ich mach aber mal Dampf.

Zitat:

Zitat von jobo (Beitrag 1098460)

Welche Clientversion von Oracle wird denn derzeit eingesetzt?

9 auf den alten, 11 auf den neuen Rechnern. Die Datenbanken sind 10. Sobald die erste 11er DB kommt, funzt der 9er Client nicht mehr wirklich, dann wird alles auf 11 umgestellt.

Zitat:

Zitat von jobo (Beitrag 1098460)

LONG ist ja per se eher selten (max ein Feld pro Tabelle?). Also einfach sparsam verwenden. :)
Es dürfte sowieso keine Anwendung geben, die Felder bis 2Gb Größe im Normalbetrieb bis ins GUI schleppt. Wenn dann nur auf Anforderung und das kann man ja dann gezielt per Stored Proc regeln, solange man nicht migrieren kann/darf.

Wie gesagt, wir habens nicht verbrochen und müssen nur damit leben, dass der Hersteller der Software diese Felder nicht anpacken will. Da jetzt mit Stored Procs einzugreifen und sowas wie eine migration on the fly umzusetzten ist glaub ich zu riskant und aufwendig, da bei jedem Releasewechsel, alle paar Monate, alles geprüft werden müsste. Das ist zuviel Aufwand für die paar Auswertungen, die wir zusätzlich zu denen der Software, aus der Datenbank ziehen.

Mit dem direkteren Zugriff (ohne ODBC), wenn es nötig ist, bin ich erstmal zufrieden.
Danke nochmal!