Probleme mit Delphi, ADO und Oracle

[greenmile]

Wir setzen Delphi 5 Enterprise zusammen mit Oracle 9i Datenbankserver ein. Bisher kommunizierte unsere Software nur via ADO (2.8, alle Delphi Updates geladen) mit einem SQL-Server 2000, was problemlos funktioniere. Nun muß die Software mit Oracle 9i zusammenarbeiten. Wir verwenden persistente Felder. Das Problem ist, dass Delphi keine bool'schen Felder und keine Integer Felder von Oracle erkennt und diese stattdessen als TFloatField ausgibt. Diese Probleme haben wir nicht nur mit den ADO-Komponenten (TAdoTable), sondern auch mit anderen (z.B. SQL-Direct). Ich konnte leider nicht herausfinden, wieso Delphi den Datentyp "Boolean" bzw "Integer" nicht als solchen erkennt. Kennt hier jemand eine Lösung? Ich kann nicht so recht rausfinden, an wem es nun eigentlich liegt. An Delphi? An ADO? An Oracle? Oder einfach nur ein Konfigurationsproblem?

[shmia]

Welchen OLE-DB Provider verwendest du?
Es gibt 2 davon:

Code:

Provider=msdaora         Hersteller=Microsoft
Provider=OraOLEDB.Oracle Hersteller=Oracle

Der OLE DB Provider von Oracle ist spürbar besser als der von Microsoft.
Jede Oracle Version hat auch
1.) die passende Oracle Client Software
2.) den passenden OLE-DB Provider
Nur wenn 1.) & 2.) auf dem Rechner installiert sind, sind die Vorraussetzungen für korrekte DB-Verbindung vorhanden.

[greenmile]

Wow das ging ja schnell :) Wir verwenden OraOLEDB.Oracle sowie den aktuellsten Client. Wie gesagt wird ja alles von Delphi erkannt, also TDateTimeField, Blob's, Strings. Nur halt Integer und Bool nicht.

[rwachtel]

Oracle kennt weder Integer noch Boolean.

http://download-uk.oracle.com/docs/c...4/c13datyp.htm

Irgendwie habe ich gerade ein Deja-vu:

http://groups.google.com/group/de.co...65c17c8f1f915f

;)

[shmia]

Zitat:

Zitat von greenmile

Wie gesagt wird ja alles von Delphi erkannt, also TDateTimeField, Blob's, Strings. Nur halt Integer und Bool nicht.

Sind das "echte" Integerfelder (mit 16 oder 32 Bit Speicherbedarf) oder sind das Ableger des NUMERIC-Datentyps?
Ich glaube Oracle bildet den Datentyp "INTEGER" auf NUMERIC(x,0) ab.
Und Delphi bildet Numeric-Felder auf TFloatField oder TBCDField ab.

[rwachtel]

Ebend. Interessant wäre auch eine Beantwortung der in der entsprechenden Newsgroup schon gestellten Frage (s.o.), wie denn das Boolean-Feld in die Oracle-Datenbank gekommen ist... ;)

[greenmile]

Versuche natürlich überall, Hilfe zu bekommen ;)

Bool'sche Felder (vom Oracle Migrationsassistenten) werden als NUMERIC (0,1) (oder war es 1,0?) abgebildet.

[rwachtel]

Es war (1,0). ;)

Dann hast Du ja die Antwort für das Verhalten. Woher soll Delphi denn wissen, ob NUMERIC (1,0) ein Boolean ist oder ein numerisches Feld der Länge 1?

[greenmile]

Boolean wird doch immer so ausgedrückt. Schon Delphi 1 konnte mit Oracle umgehen; ich kann mir nicht vorstellen, dass Oracle damals Bool'sche Werte anders ausgegeben hat als jetzt. Das ist der Punkt den ich nicht verstehe.

Nachtrag: Ich habe mal testhalber eine Tabelle von Oracle und eine vom SQL-Server in Access importiert. Vom SQL-Server import werden logische Felder als Ja/Nein Feld importiert, von Oracle kommen nur Zahlenfelder mit "Genauigkeit 1, Dezimalstellen 0". Ich denke mal, irgendwas läuft da im ADO, Oracle Client oder Oracle Server schief ...

[rwachtel]

Nein, da läuft gar nichts schief. Das ist einfach per Definition so. Der SQL Server kann halt auch mit Bitfeldern umgehen, was Oracle nicht kann.

Aber wo ist denn das eigentliche Problem? Ich kann doch - wenn ich denn unbedingt mit Feldpersistenz arbeiten will - auch ein TBCDField z.B. an eine DBCheckbox binden.

[greenmile]

Zitat:

Zitat von rwachtel

Aber wo ist denn das eigentliche Problem? Ich kann doch - wenn ich denn unbedingt mit Feldpersistenz arbeiten will - auch ein TBCDField z.B. an eine DBCheckbox binden.

Wenn ich "EnableBCD" aktiviere/deaktiviere, bekomme ich aber immer die Fehlermeldung "Integer erwartet, aber BCD gefunden". Bzw gleiches für "Boolean erwartet, aber ..."

[rwachtel]

Das war nur ein Beispiel - Du kannst auch z.B. ein TFloatField nehmen und dieses z.B. an eine DBCheckBox binden.

[greenmile]

Das kann sein, ich komme aber schon nicht über die Fehlermeldung des Feld-Designers (bzw beim öffnen mit definierten Feldern) hinaus. "Integer erwartet, aber BCD gefunden". Bzw gleiches für "Boolean erwartet, aber ..."

[rwachtel]

Dass Du beim Wechseln der Datenbank die persistenten Felder komplett neu erstellen musst, ist aber schon klar, oder?

Das ist halt auch der Grund, warum die integrierte Feldpersistenz keine kluge Wahl spätestens bei Unterstützung alternativer Datenbanken darstellt (das Problem existiert ja nicht nur bei einem Wechsel von MS SQL zu Oracle). Aber das hat Dir Marian in der Newsgroup ja auch schon dargelegt.

[greenmile]

Das stimme ich Dir zum Teil zu, Feldpersistenz hat aber durchaus seine Vorteile; wenn man nicht gerade zu Oracle wechselt, die nicht mal AutoInc Felder haben :evil: Ich werde mal versuchen, die problematischen Felder in TVariantField abzuändern. Mal schauen was dann passiert. Ich muß ca 200 Dialoge, die teilweise sehr komplex sind und intensiv Feldpersistenz nutzen, übersetzen. Und das in 1 Monat, dann muß eine Beta laufen ...

[rwachtel]

Zitat:

Zitat von greenmile

[...] Feldpersistenz hat aber durchaus seine Vorteile [...]

Welche denn, die nicht im Code realisiert werden könnten (sprich z.B. die manuelle Erzeugung persistenter Tabellenfelder abhängig von der eingesetzten Datenbank)?

Zitat:

Ich werde mal versuchen, die problematischen Felder in TVariantField abzuändern. Mal schauen was dann passiert.

Viel Glück. Lass mal hören, was das gibt.

Zitat:

Ich muß ca 200 Dialoge, die teilweise sehr komplex sind und intensiv Feldpersistenz nutzen, übersetzen. Und das in 1 Monat, dann muß eine Beta laufen ...

Brauchst Du Unterstützung? ;)

Für die Zukunft schonmal über eine Middle-Tier-Lösung nachgedacht? Ich denke da z.B. an RemObjects' DataAbstract, mit dem ich schon sehr gute Erfahrungen machen konnte (allerdings mit Delphi 2006).

[Elvis]

Zitat:

Zitat von greenmile

Das stimme ich Dir zum Teil zu, Feldpersistenz hat aber durchaus seine Vorteile; wenn man nicht gerade zu Oracle wechselt, die nicht mal AutoInc Felder haben :evil:

Du hast mit MSSQL ja auch eine Grundlage. die glücklicherweise nicht als der Normalfall betrachtet werden kann.
AutoInc gibt es nur in DBMS', die keine Trigger unterstütz(t)en, wie mySQL, oder die eher als serverseitiges MS Access durchgehen, wie MSSQL.
Falls du irgendwann auch noch andere DBMS (wie Firebird) unterstützen willst, würde ich hingehen und deine Boolean zu numerischen Feldern ändern.
TVariantField it so ziemlich das übelste was es gibt, da Variant nicht mehr Kompatibilität bietet, es knallt einfach nur zur Laufzeit. ;)

[greenmile]

MSSQL als serverseitiges Access zu betrachten ... Nun ja, Ansichtssache. MS SQL hat in einigen Dingen die Nase ganz schön vorn, angefangen beim Kompfort, den Oracle schlichtweg nicht mitbringt. Ein Import-/Export Assistent, von dem Oracle träumt. Und AutoInc Felder sind schnell definiert, mehr möchte ich auch gar nicht; wieso sollte ich erst 2, 3 Statements losschicken, nur um etwas so profanes wie AutoInc Felder zu bekommen? Aber wie gesagt ... Ansichtssache :)

Die AutoInc/Bool'schen Felder sind leider nicht mein einziges Problem; Integer kommt noch dazu. Wobei alles letztendlich Zahlen sind, also Numeric. Kann ich im Oracle irgendwo definieren, dass ein Integer = ein Delphi Integer ist, also 32 bittig? Ich tippe mal darauf als Problem. Wir können ja schlecht die einzigen sein, die Delphi 5 > ADO > Oracle mit Feldpersistenz einsetzen. Zumal es ja nicht an ADO liegt, habe ja schon SQLDirect getestet und hatte selbiges Problem. Bleibt nur noch Delphi / Oracle Client / Oracle Server als mögliche Ursache.

[shmia]

Dein Problem sind offensichtlich die persistenten Felder!!
Leider gibt es normalerweise nur die Möglichkeit (pro Tabelle/Query) auf die persistenten Felder ganz zu verzichten
oder nur mit den persistenten Feldern zu arbeiten.
Ohne persistente Felder hättest du jetzt kein Problem mit Oracle.

Wäre es nicht toll, wenn es einen Zwischenweg geben würde?
Also die Felder werden aus der darunterliegenden Abfrage/Tabelle erzeugt und danach werden
gewisse Properties (EditFormat, EditMask, ReadOnly, Visible,...) geändert.
Leider wurde dies von Borland so nicht designed, aber man kann sich behelfen, wenn man im Event AfterOpen eingreift:

Delphi-Quellcode:

procedure TForm1.Table4711AfterOpen(dataset:TDataset);
begin
   dataset.FieldByName('PKey').Visible := False;
   dataset.FieldByName('Feld42').ReadOnly := True;
...   
end;

Mit etwas Gehirnschmalz kann man das Ganze so automatisieren, dass die Schreibarbeit deutlich reduziert wird.

[greenmile]

Zum aktuellen Stand der Dinge: Es sind irgendwie alle Schuld :)

- AutoInc
Ich habe mittels "Suchen/Ersetzen" in allen PAS und DFM alle Vorkommen von TAutoInc gegen TVariant bzw TInteger bzw TFloat ausgetauscht, damit ist dieses Problem behoben (TVariant bietet sich an, damit es mit SQL-Server weiter läuft).

- Boolean
Der Oracle Migrationsassistent setzt für Bool'sche Werte einfach NUMBER(1) ein, was Delphi bzw Access nicht korrekt erkennt. Wird der Datentyp gegen CHAR(1) getauscht, funktioniert es. Ich wechsele nun den Migrationsassistent. Falls jemand einen guten (für Geld) kennt ... Alternativ wäre auch interessant ob man Delphi "sagen" kann, dass es NUMBER=0 als False bzw NUMBER=1 als True erkennt. Ich habe keinen Weg gefunden. Ev DB.PAS modifizieren? Ich brauche Bool'sche Werte, damit ich mit ".AsBoolean" arbeiten kann.

- Integer
Delphi 7 erkennt Integer, nur Delphi 5 erkennt Float. Warum? Ich denke mal, hier müssen Änderungen in der DB.PAS vorgenommen werden. Falls jemand eine Idee hat ...


[quote="shmia"]Dein Problem sind offensichtlich die persistenten Felder!!
Leider gibt es normalerweise nur die Möglichkeit (pro Tabelle/Query) auf die persistenten Felder ganz zu verzichten
oder nur mit den persistenten Feldern zu arbeiten.
Ohne persistente Felder hättest du jetzt kein Problem mit Oracle.[/delphi]

Jein. Im Prinzip gebe ich Dir Recht, allerdings würde ich dann über andere Probleme wie Boolean stolpern. Es sind einige Probleme ...

[quote="shmia"]Leider wurde dies von Borland so nicht designed, aber man kann sich behelfen, wenn man im Event AfterOpen eingreift[/delphi]

Stimmt, leider ist Delphi hier wenig flexibel. Brachial mit "Kann damit nicht umgehen" statt ein Ereignis auszulösen damit die Anwendung die Chance hat, den neuen Datentypen zu definieren, ist wirklich unschön.