Hallo zusammen,

ich habe hier ein SQL in einem TQuery-Objekt. In diesem Query gibt es ein Subquery, dass ein COUNT() durchführt.
Die Spalte ist in Delphi mit dem Feldeditor verknüpft und zwar als Integer-Feld (COUNT() liefert ja keine Nachkommastellen).

Nun hatte ich unter Oracle10g das Problem, dass er Integer erwartet, aber Float geliefert bekommt. Das konnte ich umgehen, indem ich in der BDE die Einstellung "ENABLE INTEGERS" auf "TRUE" gesetzt habe und das Subquery auf NUMBER(10) geCASTed habe.

Das funktioniert jetzt unter Oracle9i (9.2.0.5) leider nicht. Egal ob ich es als NUMBER(10), NUMERIC(10) oder INTEGER caste, ich bekomme immer die Meldung "Unterschiedliche Typen für Feld '<Feldname>'; erwartet: Integer, gefunden: Float".
Selbst wenn ich das Subquery durch "-1" ersetze, erkennt die BDE das Feld nicht als Integer.

Hat jemand eine Idee, was ich noch versuchen könnte oder kennt gar die Lösung?

Probiere mal AsVariant.
Besser wäre es aber, wenn Du die BDE rausschmeißt.

EDIT:
Du benutzt den Feld-Editor und die BDE?
Also auch noch persistente Felder! Ich lasse meine Meinung dazu mal außen vor.

Das wird eine endloses Gebastel. Es mag sein, dass das irgendwie hinzubekommen ist, aber rechne mal aus, wieviel Zeit Du für solche Probleme aufwänden musst und was Du an Zeit sparst, wenn Du native Zugriffskomponenten für Oracle verwendest. Gerade die BDE verwuselt bei Oracle schonmal was bei den Feldtypen. Insbesondere, wenn du auch noch verschiedene Oracle-Versionen benutzt.

BDE ist nunmal uralt und hat keinerlei anpassungen an Oracle 8/9/10/11 erhalten. Da kanns es schon mal an jeder Ecke bei einem Oracle-Versionswechsel krachen.

Dass die BDE uralt ist (seit 2001/02 nicht mehr gepflegt wird) weiß ich, allerdings können/wollen wir keine nativen Komponenten einsetzen, da wir nicht nur Oracle sondern auch MSSQL und Informix unterstützen (bis vor kurzem sogar noch Interbase).

Die Verknüpfung per Feldeditor ist auch keine Idee von mir, sondern schon immer so gewesen und "einfach so umstellen" geht auch nicht (mehr).

Ich hab' mir jetzt soweit geholfen, dass ich das Feld als String caste und dann in Delphi in Integer umwandel.

Interessant: Oracle 10g funktioniert problemlos.

baka0815 hat folgendes geschrieben :

Dass die BDE uralt ist (seit 2001/02 nicht mehr gepflegt wird) weiß ich, allerdings können/wollen wir keine nativen Komponenten einsetzen, da wir nicht nur Oracle sondern auch MSSQL und Informix unterstützen (bis vor kurzem sogar noch Interbase).

Na und? Hierfür gibt es auch Lösungsansätze. Die Unidac-Komponenten von DevArt wären sowas oder eine eigene Implementierung mit Hilfe des Bridge-Pattern

Wie Bernhard schon schreibt, gibt es auch gute Komponenten, die ohne BDE auskommen und trotzdem mehrere DB-Systeme unterstützen.

Aber ich kann auch verstehen, dass ihr nicht mal eben so bestehende Projekte umstellen könnt oder wollt. Da muss viel Arbeit, Zeit und Geld reingesteckt werden. Allerdings kann es auch nicht sein, dass ihr auf eine so veraltete Technologie setzt. Irgendwann wird die BDE nicht mehr funktionieren. Ich könnte mir gut vorstellen, dass es schon unter 64-Bit-Betriebssystemen schwierig wird. Ausprobieren werde ich es aber nicht.

Denkt also rechtzeitig an eine Umstellung.

jasocul hat folgendes geschrieben :

Irgendwann wird die BDE nicht mehr funktionieren. Ich könnte mir gut vorstellen, dass es schon unter 64-Bit-Betriebssystemen schwierig wird. Ausprobieren werde ich es aber nicht.

Es soll mit Tricks halbwegs gehen. Hinweise dazu gibt es in den Codegear-Foren

jasocul hat folgendes geschrieben :

Denkt also rechtzeitig an eine Umstellung.

Der war gut. Rechzeitg wäre Anfang des Jahrtausends gewesen.

Bernhard Geyer hat folgendes geschrieben :

jasocul hat folgendes geschrieben : Irgendwann wird die BDE nicht mehr funktionieren. Ich könnte mir gut vorstellen, dass es schon unter 64-Bit-Betriebssystemen schwierig wird. Ausprobieren werde ich es aber nicht. Es soll mit Tricks halbwegs gehen. Hinweise dazu gibt es in den Codegear-Foren

Japp, funktioniert unter Windows 7 64-Bit bisher problemlos. Nur die PDOXUSERS.NET-Datei wird standardmäßig unter C:\ abgelegt, auf das man als normaler Benutzer keine Rechte hat - aber das kann man ja konfigurieren.

Wir sind auch dabei neben der normalen Entwicklung Stück für Stück auf andere DB-Komponenten umzusteigen - bei akuten Problemen hilft das aber leider gar nix!