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.
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.
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!