BDEClientDataset & SQL-Error

[stalle]

Hallo Leute, <br>
<br>
Ich brauche mal wieder Eure Erfahrungen. Ich habe ein BDEClientDataset, TDBNavigator,
ein TDBGrid und jede Menge TDBEdit's in einer Groupbox. Die Applikation tut mittlerweile sogar was Sie soll. ;-)) Ich habe aber das Problem,das wenn der Eingabefocus auf einem der DBEdit's stand und ich irgendwo anders hinklicke, die SQL Fehlermeldung : "Key violation. [Openlink][ODBC][Progress] ** Unknown Field or Vaiable name - B ." bekomme. Dieses Verhalten ist reproduzierbar. Wie gesagt, es passiert NUR wenn ich aus einem der DBEdit's raus will. Satzanfügen, löschen etc. funzt alles tadellos. Hat jemand'ne Idee, wie ich dem Übeltäter auf die Schliche komme ? Was mich nachdenklich stimmt, ist, das DBGrid tadellos funzt und nur die DBEdit's den Ärger machen. Beide greifen auf das selbe Dataset zu. Dieses wird auch (zumindest an dieser Stelle) nicht mehr geändert. Die Anzahl der Sätze im Zugriff spielen auch keine Rolle. Egal ob 100 oder 0. Das die Fehlermeldung von der Datenbank bzw. dem ODBC-Treiber kommt ist auch klar.<br>
Vielleicht hat jemand von Euch auch sowas erlebt und weiß wie man rausfindet wo der Fehler liegt.<br>
<br>
Viele Grüße <br>
Axel

[Andreas Kosch]

Hallo,

Borland hat mit Delphi 6 einen Bug (TFieldDataLink.UpdateField) neu ausgeliefert, der bei Delphi 5 im UpdatePack#1 beseitigt wurde. Dieser Bug sorgt dafür, dass die Synchronisation von TDBEdit im Gegensatz zu TDBGrid nicht mehr in allen Fällen korrekt abläuft.

Ist die Datenmenge zu diesem Zeitpunkt im Edit-Modus? Wenn ja, sollte TBDEClientDataSet auch beim automatischen Posten dieses Datensatzes niemals sofort zur Datenbank zurückschreiben. Wenn TBDEClientDataSet eingesetzt wird, greift doch erst ApplyUpdates auf die originale Datenbank zu, so dass erst zu diesem Zeitpunkt ein Veto vom ODBC-Treiber kommen dürfte.

Lässt sich dieser Effekt in einem kleinen Beispiel reproduzieren

[stalle]

Hallo Andreas,<br>
kann das von Dir beschriebene Szenario denn auch auftreten, wenn KEIN Satz im Zugriff ist ? Denn dann gäbe es ja nichts zum zurückschreiben.
Denn selbst wenn ich keinen neuen Satz produziere und nur mit dem Cursor im Eingabefeld stehe und in ein anderes Feld klicke tritt der Fehler auf.<br><br>
Gruss Axe

[stalle]

Ich neige nun doch dazu anzunehmen, das es ein Bug der BDE ist. Ich ändere den CommandText nur in Abhängigkeit von der Datumseingabe des Users. Wenn ich diese Funktion überspringe, d.h. mit dem Originalstring arbeite, tritt der Fehler genauso auf. Ich habe folgende Procedure gemacht : <br><br>
procedure TForm2.DBEArtikelExit(Sender: TObject);<br>
begin<br>
ShowMessage(BDEClientDataSet1.CommandText);<br>
end;<br>
Dies liefert mir den korrekten SQL-Befehl : <br>
select * from pro1.DruckPartie Where Datum = Date("07.06.01")<br>
<br>
Danach tritt dieser Fehler auf. Seltsam, seltsam. An welcher Stelle könnte ich den den Fehler mit try except abfangen ?

[Andreas Kosch]

Hallo,

wann wird ApplyUpdates aufgerufen? Was passiert, wenn alle diese Aufrufe auskommentiert werden

[stalle]

Tja, und wieder mal bewahrheitet sich der Spruch : "Kannst Du keinen Fehler finden, suchst Du an der falschen Stelle.". Es lag natürlich an mir. Die DBEdit's befinden sich in einer GroupBox. Auf mir immer noch unerklärliche Weise ist für diese Groupbox im OnExit-Event ein Aufruf einer Prozedur aus einem völlig anderen Programmteil erfolgt, der eigentlich nix mit den DBEdit's zu tun hat. Zu diesem Zeitpunkt, waren die Variablen dieser Query aber noch gar nicht initialisiert. Da auch die ODBC-Fehlermeldung nicht gerade selbsterklärend war, bin ich ziemlich in die Irre geführt worden. <br>
Trotzdem, vielen Dank für Deine Mühe, Andreas !!<br>
<br>Gruss Axe