Wer löst diese Exception aus?



  • Ich erhalte folgenden Fehlermeldung:
    Exception der Klasse EDDatabaseError -> Meldung: 99999999999999999999999999999999999 ist kein gültiger Fließkommawert für Feld XYZ.

    Ich greife klassisch auf meine DB zu.
    ADOConection1->ADOQuery1->DataSource1->DBGridX
    ADOConection1->ADOQuery1->DataSource1->DBEditY

    Die Exception tritt auf, wenn ich im Grid oder über DBEdit einen Numeric-Wert (sinnlos) ändere und dann die Zelle/das Edit verlasse.

    Jetzt würde ich die Exception gern abfangen (try/catch).

    Allerdings habe ich bisher vergeblich die Stelle gesucht, an der ich try/catch ansetzen muß.

    Testweise habe ich dazu mit catch(...) gearbeitet.

    Auch TApplicationEvents->OnException habe ich testhalber auch schon eingebaut. Das wird auch abgearbeitet, aber erst nach der Exception-Anzeige nicht statt dessen.

    Wer hat's erfunden ? 😕

    PS: Ich vergaß zu erwähnen. Das Ereignis DBEdit->OnExit wird danach nicht ausgelöst.



  • Ich würde es mal mit den Ereignissen
    OnWillChange...
    oder
    OnPostError oder OnEditError
    versuchen.
    Habe ich allerdings keine Erfahrung mit.



  • Leider nein. Die Palette von DataSet habe ich inzwischen auch schon durchgetestet.

    Er kommt logischerweise an BeforeEdit vorbei aber nicht mehr bei OnWillChangeField oder AfterEdit an.

    Hinweis

    Die Feldobjekte der Recordset-Komponente unterscheiden sich von den VCL-Feldobjekten der ADO-Datenmenge. Das Ereignis OnWillChangeField tritt nur bei Recordset-Objekten ein und wird unabhängig von den Änderungsereignissen der VCL-Felder ausgelöst.

    Wie komme ich an die "Änderungsereignisse der VCL-Felder" ran?

    Gut; DBEdit könnte ich mit OnChange vor der Exception abfangen, aber die Änderungen im Grid?



  • caspar_louis schrieb:

    Leider nein. Die Palette von DataSet habe ich inzwischen auch schon durchgetestet.

    Meinem Verständnis nach, muß aber doch von dem, mit dem Grid verknüpften DataSet, ein entsprechendes Ereignis ausgelöst werden. Entweder OnPostError, oder OnEditError.

    Aus der Hilfe des BCB zu TADODataSet::OnError():

    Beschreibung

    Mit einer Ereignisbehandlungsroutine für OnEditError können Exceptions verarbeitet werden, die bei einem fehlgeschlagenen Bearbeitungsversuch eines Datensatzes auftreten.

    DataSet gibt die betreffende Datenmenge an. E ist ein Zeiger auf das Fehlerobjekt mit den Exception-Informationen. Dieses Objekt kann in einer Fehlerbehandlungsroutine zur Anzeige einer entsprechenden Fehlermeldung verwendet werden. Action gibt an, wie die Datenmenge auf den Fehler reagieren soll.

    Beim ersten Aufruf der Ereignisbehandlungsroutine OnEditError wird Action immer auf daFail gesetzt. Kann in der Fehlerbehandlungsroutine die Fehlerbedingung beseitigt werden, setzen Sie Action vor Beenden der Routine auf daRetry. Die Operation wird dadurch erneut durchgeführt.

    Kann die Fehlerbedingung nicht korrigiert werden, können Sie die Anzeige der Fehlermeldung verhindern, indem Sie Action auf daAbort und nicht auf daFail setzen.

    Also sollte das doch eigentlich der richtige Weg sein. Beißt sich das vielleicht, mit der, dem gleichen Feld zugeordneten TDBEdit?



  • Schön wär's ja. Ich habe testhalber alle in Frage kommenden Events mit MsgDlg's belegt und zusätzlich BreakPoints gesetzt, um mich durchzudebuggen.

    Er kommt bei keinem Breakpoint nach der Exception an.

    Wenn ich Einzelanweisungen(F7) ausführe, passiert gar nichts. Führe ich nächste Quelltexzeile aus (Umsch+F7), dann krieg ich den Dialog der Exception und bin wieder in der Zelle/dem DBEdit.

    Nach der Exeption steht er hier:

    void __fastcall TMainForm::FormActivate(TObject *Sender)
    {
       ml2 = new TMainMLVisard(this);
       ml2->ShowModal();
       // **** genau hier im Delete ****
       delete ml2;
    
       MainForm->Close();
    /* Diese besch... Hilfskonstruktion brauch ich, weil ich ein modales Fenster brauche. 
    Sonst zerstört meine rufende Appl (Centura-SAL -> SalApplicationAndWait(...) ) das Form gleich wieder. */
    }
    

    Ich glaube auch nicht, daß es mit DBEdit zu tun hat. Um das auszuschließen habe ich es auch mal "abgehängt". Geändert hat das nichts.


Anmelden zum Antworten