Ungültige Gleitkommaoperation nur bei bestimmten PC's

[DeddyH]

StrToInt hat aber doch mit Gleitkomma nichts zu tun, ansonsten würde ich eher mit einem EConvertError rechnen, wenn man Stringumwandlungen versucht.

[HCB]

Die Variable dummy ist vom Typ cardinal, ich werde es mal auf Integer oder LongInt umstellen und sehen was dann passiert.
Fragt sich nur warum es bei 2 Rechnern ohne Fehlermeldung läuft.???

[Delphi.Narium]

Wenn statt einer MessageBox, außerhalb der Fehlerbehandlungsroutine zur Flusssteuerung, eine andere Fehlermeldung kommt, liegt die Vermutung nahe, dass die andere Fehlermeldung nicht von dort kommt, wo du es vermutest oder gerne hättest, sondern von einer anderen Stelle.
Oder die Fehlerbehandlung selbst enthält einen Fehler, so dass dort nicht die gewünschte Fehlerbehandlung erfolgt, sondern ein Folgefehler sichtbar wird.

haentschman bat um Code. Wie wäre es damit? Dann hätten wir sogar 'ne Chance die Fehlerstelle mal anzuschauen, den Fehler nachzuvollziehen, für Abhilfe zu sorgen, statt einfach nur in Mutmaßungen zu stochern.

Zitat von himitsu:

Aber ein Fließkommafehler bei einer Ganzzahloperation?

Wie kommst Du dadrauf?

StrToInt(eingabetext) suggeriert zwar, dass hier die Eingabe zu 'nem Integer werden soll, aber ob die Eingabe ein Integer ist, wissen wir nicht.

Ist Eingabetext auf manchen Systemen ein Integer mit Tausenderpunkt, der auf anderen Systemen zu 'nem Dezimaltrenner mutiert? Oder ist die Eingabe zwar für StrToInt ein "richtiger" Integer, für die weitere Routine aber nicht?

Und was kommt hier auf welchem Weg nach Eingabetext? TEdit, TMemo, TMaskEdit, InputQuery, InputBox, ...

Und wo sucht die Suchfunktion? In 'ner Ini, im Arbeitsspeicher, 'ner StringList, 'ner Datenbank? Passen da die Ländereinstellungen überall zusammen?

Delphi mit Tausenderpunkt, Datenbank mit Tausenderkomma? Integer mit Tausenderpunkt ist Integer. Mit Tausenderkomma aber eventuell bei der DB dann nicht mehr. Oder was weiß wer da sonst noch so alles schiefgehen könnte, ...

[HCB]

Hier der Code-Ausschnitt:

Delphi-Quellcode:

           try
            dummy:=StrToInt(edt_SearchEdit.Text); //prüfen ob artikelnummer eingegeben wurde, sonst except ausführen
            Q_sArtikel.close;
            Q_sArtikel.SQL.Text:='select * from Artikel where ArtNr like '+ QuotedStr(edt_SearchEdit.Text+'%')                   
            Q_sArtikel.open;                
           except on E: EConvertError do   ShowMessage('Keine gültige Artikelnummer';
           end;

LG Harry

[Bernhard Geyer]

HP Treiber installiert?
(gab es jedenfalls mal vor Jahren, das diese "ein paar Einstellungen" für alle Programme beeinflusst haben.

[himitsu]

Zitat von Delphi.Narium:

StrToInt(eingabetext) suggeriert zwar, dass hier die Eingabe zu 'nem Integer werden soll, aber ob die Eingabe ein Integer ist, wissen wir nicht.

Es ist egal, was übergeben wird, es kann auch garnichts, oder der Name "Hans Peter" sein.
Es wird als Ganzzahl interpreziert und demnach auch so behantelt.
Sollte es nicht passen, dann kommt ein anderer Fehler, aber eben nichts bezüglicgh Fließkomma.

Und ja, natürlich kann (oder wird vermutlich auch) der Fehler von wo Anders her kommen.

[Klaus01]

.. du kannst Dein Edit auch so einstellen, dass es nur Zahlen/Ziffern akzeptiert.

Grüße
Klaus

[HCB]

Im Suchfeld sollen Artikelnummern und Produktbezeichnungen eingegeben werden können, wobei wenn Artikelnummern eingegeben werden eine andere SQL abfrage gestartet wird.
Ich habe das ganze jetzt mal auf "tryStrToInt" umgestellt und statt der var cardinal Integer zugewiesen. Mal sehen obs dann richtig läuft.
Gebe auf jedenfall morgen bescheid. Drückt mir die Daumen.

LG Harry

[himitsu]

bis 9 bzw. 10 Dezimalstellen
TryStrToInt
TryStrToUInt

bis 19 bzw. 20 Dezimalstellen
TryStrToInt64
TryStrToUInt64

[Delphi.Narium]

Zitat von himitsu:

Zitat von Delphi.Narium:

StrToInt(eingabetext) suggeriert zwar, dass hier die Eingabe zu 'nem Integer werden soll, aber ob die Eingabe ein Integer ist, wissen wir nicht.

Es ist egal, was übergeben wird, es kann auch garnichts, oder der Name "Hans Peter" sein.
Es wird als Ganzzahl interpreziert und demnach auch so behantelt.
Sollte es nicht passen, dann kommt ein anderer Fehler, aber eben nichts bezüglicgh Fließkomma.

Und ja, natürlich kann (oder wird vermutlich auch) der Fehler von wo Anders her kommen.

Das ändert nichts daran, dass wir nicht wissen (wussten), welche konkrete Eingabe zum konkreten Fehler führt(e).

Es ist klar, das dummy nach dem StrToInt 'nen Integer enthält oder eine Ausnahme ausgelöst wird. Enthält dummy einen Integer, wird eine Abfrage mit dem Inhalt von Eingabetext erstellt. Von welchem Type die Artikelnummer in der Datenbank ist, wissen wir nicht, durch die Nutzung von Like könnte hier aber (datenbankseitig) eine implizite Typumwandlung erfolgen, die aber höchstwahrscheinlich nicht zum genannten Fehler führen wird.

Zitat von HCB:

Im Suchfeld sollen Artikelnummern und Produktbezeichnungen eingegeben werden können, wobei wenn Artikelnummern eingegeben werden eine andere SQL abfrage gestartet wird.
Ich habe das ganze jetzt mal auf "tryStrToInt" umgestellt und statt der var cardinal Integer zugewiesen. Mal sehen obs dann richtig läuft.
Gebe auf jedenfall morgen bescheid. Drückt mir die Daumen.

Die gezeigte Quelltext lässt vermuten, dass es sich hier um eine andere SQL abfrage, der Abfrage nach Artikelnummer, also um die andere Abfrage, handelt.

Der Fehler tritt aber auf, wenn man unsinniges wie "hehfehehefgh" eingibt. Also bei der Abfrage, deren Verarbeitung wir im Quelltext nicht sehen können.

Wir wissen, dass mit einer Datenbank gearbeitet wird, wir wissen aber nicht welcher. Stimmen die Ländereinstellungen, ... der Datenbanken auch alle überein?

Der genannte Fehler könnte z. B. eventuell auch auftreten, wenn Client und Datenbank Komma und Tausenderpunkte unterschiedlich interpretieren. Dann könnte er beim Open der Abfrage auftreten, wenn der Client einen Integer erwartet, aber 'nen Gleitkommawert erhält oder andersherum oder irgendsowas, was leicht bis mittelstarkt durcheinandergeraten ist. Fehlerverursacher muss jedenfalls nicht zwingend die Artikelnummer sein, sondern könnte auch aus einem (wie auch immer gearteten) Konvertierfehler einer der anderen im select * from enthaltenen Spalten resultieren.

Zitat von Jasocul:

Bist du dir sicher, dass du den Fehler an der richtigen Stelle suchst?

Ich bin mir (fast) sicher, dass der Fehler an der falschen Stelle gesucht wird.