Oracle Bug oder bin ich zu blöd?

[BeerBear]

Moin,

ich habe ein sehr merkwürdiges Problem mit dem Oracle 8 Client.
Ich benutze TUpdateSQL und wenn ich in ein Feld schreibe, das noch den Wert NULL enthält, klappt alles wie es soll.
Führe ich jedoch ein weiteres Update auf ein weiteres NULL Feld durch, wird dieses nicht mehr in die Datenbank geschrieben.

Hier mal ein Codebeispiel: (alle Felder enthalten den Wert NULL)

Delphi-Quellcode:

  with Query1 do
    begin
      Edit;
      FieldByName('GANZZAHL').AsInteger := 10;
      Post;
      ApplyUpdates;
      CommitUpdates;

      Edit;
      FieldByName('DATUM').AsDateTime := StrToDate(Edit3.Text);
      Post;
      ApplyUpdates;
      CommitUpdates;

      Edit;
      FieldByName('TEXT').asString := 'Ich bin der Text';
      Post;
      ApplyUpdates;
      CommitUpdates;
    end;

Mit diesem Code würde nur im Feld GANZZAHL eine 10 erscheinen. Alle anderen blieben leer. Unabhängig vom Datentyp. Es wird nur das erste Update ausgeführt.
Updates auf Felder, die bereits Werte enthalten, werden wie erwartet weggeschrieben.

Komischerweise tritt dieses Problem nicht mit dem Oracle 7 Client auf.
Kennt jemand das Problem?
Ist es ein Bug im Oracle 8 Client?
Oder gibt es noch irgendwelche Konfigurationen, die dieses Problem hervorrufen?

[Bernhard Geyer]

1, Schmeiß die BDE weg und nimm eine nativen Oracle-Komponente wie z.B. von Core Labs.

2, Oracle hat in jeder Version genügend Bugs. Es genügt aber nicht nur die Hauptversion anzugeben sondern du mußt die Version bis zur letzten Versionstelle angeben da zwischen Miniupdates der Fehler auftreten kann bzw. verschwinden kann

3, Wieso wird jedes einzlene Feld direkt geschrieben. Geht nicht folgendes?

Delphi-Quellcode:

with Query1 do
    begin
      Edit;
      FieldByName('GANZZAHL').AsInteger := 10;
      FieldByName('DATUM').AsDateTime := StrToDate(Edit3.Text);
      FieldByName('TEXT').asString := 'Ich bin der Text';
      Post;
      ApplyUpdates;
      CommitUpdates;
    end;
end;

Wobei ich nicht weiß ob überhaupt ApplyUpdates bzw. CommmitUpdates nötig sind. Liegt vieleicht auch daran das ich schon seit jahren nur noch mit INSERT/Update-SQL-Statements arbeite.

Ich vermute mal das nach Post, ApplyUpdates, CommitUpdates die Client oder die BDE nicht mehr den Datensatz erkennt und die falsche SQL-Updateanweisung zur DB schickt.

[BeerBear]

1.
Welchen Aufwand würde das Bedeuten bei einer großen Datenbankanwendung mit mehr als 600000 Zeilen? Ich glaube das ist kaum möglich. :pale:

2.
Oracle Client: Version 8.1.7 August 2000
Delphi: 3.0 (Build 5.83)
BDE: Ursprünglich 5.01 mit Update auf (5.11 oder 5.1.1)? Zeigt aber immernoch 5.01 an.

3.
Sicher, so würde es auch funktionieren.
Aber bei meinem Code handelt es sich nur um einen Beispielcode zum besseren Verständnis meines Problems. In der Betroffen Anwendung wird auf verschiedene Ereignisse reagiert, bei denen jeweils so ein einzelner Block ausgeführt wird.

[Bernhard Geyer]

Zitat:

Zitat von BeerBear

1.
Welchen Aufwand würde das Bedeuten bei einer großen Datenbankanwendung mit mehr als 600000 Zeilen? Ich glaube das ist kaum möglich. :pale:

Und was machst Du wenn mit dem August-Update von MS bei einem kritischen Update die BDE nicht mehr gehen würde?
Außerdem sollte man die DB-Abhänigigkeiten nicht auf 1000 Units verteilen. Wir haben 1,2 Mio. Quellcodezeilen (ok, mit Kaufkomponenten) und unsere Oracle-Abhänigkeiten sind in ca. 1000 Zeilen komprimiert.

Zitat:

Zitat von BeerBear

Oracle Client: Version 8.1.7 August 2000

Haben wir auch und keine dramatischene Probleme damit

Zitat:

Zitat von BeerBear

Sicher, so würde es auch funktionieren.
Aber bei meinem Code handelt es sich nur um einen Beispielcode zum besseren Verständnis meines Problems. In der Betroffen Anwendung wird auf verschiedene Ereignisse reagiert, bei denen jeweils so ein einzelner Block ausgeführt wird.

Kannst Du eigentlich kontrollieren was auf Oracle-Seite ankommt?

[BeerBear]

Zitat:

Zitat von Bernhard Geyer

Und was machst Du wenn mit dem August-Update von MS bei einem kritischen Update die BDE nicht mehr gehen würde?

Das ist aber sehr weit hergeholt.
Aber was ich machen soll, würde mir dann mein Vorgesetzter sagen. :-D

Zitat:

Zitat von Bernhard Geyer

Außerdem sollte man die DB-Abhänigigkeiten nicht auf 1000 Units verteilen.

Hab noch nie etwas anderes als die BDE benutzt. Deshalb frage ich ja, wie groß der Aufwand wäre. Also was müsste ich tun, um sie nicht zu benutzen?

Zitat:

Zitat von Bernhard Geyer

Haben wir auch und keine dramatischene Probleme damit.

Wir benutzen den Client auch schon etwas länger, das Problem ist nur noch nicht aufgefallen. Mal getestet, ob das Problem bei euch ebenfalls Auftritt?

Zitat:

Zitat von Bernhard Geyer

Kannst Du eigentlich kontrollieren was auf Oracle-Seite ankommt?

Versuche gerade das Tracing am Client in Gang zu bekommen. Das will aber nicht so wirklich.
Gibt es am Server auch eine Möglichkeit?

[Bernhard Geyer]

Zitat:

Zitat von BeerBear

Das ist aber sehr weit hergeholt.
Aber was ich machen soll, würde mir dann mein Vorgesetzter sagen. :-D

Wieso weit hergeholt? Wenn man sieht was MS teilweise mit Fixes verbockt (Schon mal eine CHM-Datei von Netzwerklaufwerk gestartet) würde mich nichts wundern. Und es geht darum was der Kunde sagt (wenn die Anwendung verkauft wird).

Zitat:

Zitat von BeerBear

Hab noch nie etwas anderes als die BDE benutzt. Deshalb frage ich ja, wie groß der Aufwand wäre. Also was müsste ich tun, um sie nicht zu benutzen?

Erst mal solltest Du deinen Code soweit überarbeiten das der DB-Abhänige Teil auf Wenige Units konzentriert ist. Mich wundert es das bei der größe der Anwendung noch keine diesen Teil überarbeitet hat und das eh schon versucht hat.
Anschließend kannst Du mittels Abstraktion versuchen eine DB-Unabhänige (hier meine ich das keine BDE/Oracle-Spezialitäten mehr "nach außen" sichtbar sind) Schnittstelle zu definieren.
Jetzt kannst Du eine neue DB-Zugriffsklasse implementieren welche diese Schnittstelle implementiert und z.B. native mit CoreLab-Komponenten auf die DB zugreift.

Zitat:

Zitat von BeerBear

Versuche gerade das Tracing am Client in Gang zu bekommen. Das will aber nicht so wirklich.
Gibt es am Server auch eine Möglichkeit?

Für MS SQL Server kenn ich die Möglichkeiten. Aber Oracle ... wird sicherlich wieder ein schreckliches Konsolenprogramm sein.

[BeerBear]

Zitat:

Erst mal solltest Du deinen Code soweit überarbeiten das der DB-Abhänige Teil auf Wenige Units konzentriert ist. Mich wundert es das bei der größe der Anwendung noch keine diesen Teil überarbeitet hat und das eh schon versucht hat.
Anschließend kannst Du mittels Abstraktion versuchen eine DB-Unabhänige (hier meine ich das keine BDE/Oracle-Spezialitäten mehr "nach außen" sichtbar sind) Schnittstelle zu definieren.
Jetzt kannst Du eine neue DB-Zugriffsklasse implementieren welche diese Schnittstelle implementiert und z.B. native mit CoreLab-Komponenten auf die DB zugreift.

:shock: O.K. vergessen wir das wieder.

Das Tracing läuft nun endlich

Habe den Trace mal angehängt. Dabei handelt es sich nur um den Teil, der während des oben genannten Bespielcodes entsteht. (Trace.txt)

Außerdem habe ich daraus noch die Netwerkaktivität herausgefiltert. (PacketsCU.txt)
Scheinbar wird die SQL Anweisung nur einmal abgeschickt.

[hoika]

Hallo,

funktioniert der BDE sql monitor nicht bei dir ?


Heiko

[BeerBear]

Doch, der funktioniert. Zeigt aber keine Auffälligkeiten. Dort taucht auch die SQL Anweisung noch 3 mal auf.

Nur mit der Anziege von Integern hat er scheinbar ein Problem, das ist aber immer der Fall.

[Bernhard Geyer]

Um es mal lappidar zu sagen: Hier scheint es inkompatiblitäten zwischen dieser Oracle-Version und der installierten BDE-Version zu geben. Da bei Softwaren vom Hersteller (in dieser Version) vom Hersteller nicht mehr gepflegt werden wird dir nichts übrig bleiben als:

1, Diese als Nicht-Lauffähig zu deklarieren und den Anwender eine Update nahezu legen
2, (Mal wieder) die BDE als eine Fehlerquelle abzulösen.
3, Dein Programm umzuschreiben das solche Konstrukte nicht mehr vorkommen (z.B. eigene Update-SQL-Scripte schreiben)