Ungültige Gleitkommaoperation nur bei bestimmten PC's

[haentschman]

Zitat:

QuotedStr

...CopyPaste.
Q_sArtikel.ParamByName('ANN').AsString := edt_SearchEdit.Text + '%';

[Phoenix]

Okay, die SQL-Injection haben wir jetzt gelöst. Die Exception noch nicht.

Die Exception "Ungültige Gleitkommaoperation" bei der Eingabe von Nummern riecht für mich auch Extrem nach einer Locale-Thematik.
Also wirklich checken:
- Welche Region ist auf den jeweiligen PCs eingestellt?
- Welche Sprache nutzen die jeweiligen Rechner?
- Welches "Regional Format" ist eingestellt?

Mir ist mal eine Fremdprogrammierte Java-Vereinsmanagementsoftware jedes mal bei einer Zifferneingabe abgeschmiert, weil mein System English (US) war und mein Regional Format German (Date/Time, Tausender- und Nachkomma-Trennzeichen), und der Entwickler dort halt nur auf reinen German-Systemen gearbeitet hat und der übliche Vereins-Verwaltungs-Typ maximal auch ne Deutsche Windows-Kiste hatte und das da nie vorgekommen ist.

[HCB]

So jetzt das Ergebnis
Region, Sprache etc. alles ok, bei allen Rechnern gleich.
Nochmals zur Klarstellung:
Der Fehler wird nur auf manchen Rechnern geworfen wenn man Z.B. unsinniges wie "hehfehehefgh" eingibt (nicht Zahlen!) das natürlich nicht gefunden werden kann!
Das ist kurios warum die Exception "Ungültige Gleitkommaoperation" angezeigt wird.
Die Änderungen auf TryStrToInt hat auch nichts gebracht. Gleiche Fehlrmeldung!!

Vielleicht sollte ich mal Änderungen bei Region vornehmen, speichern und wieder auf "Deutschland" einstellen. Manchmal verhält sich Windows "merkwürdig".

LG Harry

[Uwe Raabe]

Ist offenbar noch nicht nach gefragt worden: Sind Threads im Spiel?

[Jasocul]

Zitat von HCB:

Das ist kurios warum die Exception "Ungültige Gleitkommaoperation" angezeigt wird.
Die Änderungen auf TryStrToInt hat auch nichts gebracht. Gleiche Fehlrmeldung!!

Bist du dir sicher, dass du den Fehler an der richtigen Stelle suchst?
Mit TryStrToInt sollte keine Exception mehr ausgelöst werden und der SQL-Abfrage ist es egal, was in dem String steht. Abgesehen davon würde bei einem SQL-Fehler eine andere Exception ausgelöst werden.

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

[HCB]

Das blöde daran ist, dass ich auf dem Entwicklungsrechner nichts feststellen kann, da das ja auf diesem funktioniert. Ich muss erst die exe auf die anderen Rechner übertragen um festzustellen, dass es dort bei einem läuft, bei anderen aber nicht.
Ich setze mal im Code einige ShowMessages ein um genau zu sehen bei welchen Codeabschnitt die Exception bei den betroffenen Rechnern auftritt.

LG Harry

[rabatscher]

my 2 cents:
wir hatten grad ein Problem mit dem FPU Control Word :
Beim laden der fbClient.dll kam es zu einem netten Nebeneffekt, der das FPU control word so gesetzt hat,
dass die FPU Exceptions maskiert wurde - das lag jetzt mal nicht in erster Linie an Firebird (die hatten
genau diesen Fehler ausgemerzt) aber an 3rd Party dll's, die auf manchen Systemen dazugeladen wurde.
-> Bei uns hatte das genau eine FPU exception maskiert und auf anderen Rechnern Exceptions verursacht.

-> mal checken (da ich ja evt. nicht ganz falsch liege, dass du Datenbanken benutzt).

Manche FPU exceptions werden nur bei einem "Wait" asm call geworfen also hast du evt. ein
paar Assemblersequenzen, die das nicht aufrufen?

Und dann wär noch die Routine Move... sie benutzt in win32 die FPU Register um Daten zu kopieren. Wenn jetzt vorher schon
mal eine FP Exception da war könnte das da hochkommen. Und... Move wird intern wirklich oft verwendent.

[BerndS]

Wenn du da nicht weiter kommst könnte MadExcept oder ähnliche Tools eine große Hilfe sein.

[Sherlock]

Und der Remotedebugger hilft auch immer wieder.