Probleme mit TADOQuery wenn zuviele Spalten?

[Bernhard Geyer]

Zitat von Jumpy:

"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

[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 von 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.

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

Zitat von jobo:

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 von jobo:

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!