Probleme mit Delphi, ADO und Oracle

[greenmile]

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

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.