Fehler bei Gleitkommakonvertierung. Die Quelle ist ungültig.

Question

Hallo zusammen,

sporadisch bekommen wir (bzw. unsere Kunden) die folgende Fehlermeldung:

General SQL error.
Fehler bei Gleitkommakonvertierung. Die Quelle ist ungültig.

Wir benutzen Delphi in Verbindung mit der BDE zur Entwicklung und haben in diesem Fall ein PreparedStatement mit Ganzzahl- und Fließkommazahlen sowie Datumsangaben.
Die Werte werden von uns jedoch als Parameter übergeben und nicht direkt im SQL-String, daher schließe ich ein Problem mit unterschiedlichen Zeichensätzen eigentlich aus.
Trigger verwenden wir auf der Datenbank auch keine.

Aufgetreten ist dieses Problem beim SQL-Server 2005 SP1 und SP2 sowie beim SQL-Server 2005 Express SP1 und SP2. Das SP2 hat der Kunde auf unsere Empfehlung hin installiert, trotzdem tritt obiges Problem weiterhin sporadisch auf. Bevor wir dem Kunden nun empfehlen SP3 einzuspielen wüsste ich gerne, ob das Problem damit behoben ist oder ob es an etwas ganz anderem liegt.

Im Delphi-Forum habe ich die selbe Frage vor einiger Zeit gestellt, dort konnte mir jedoch niemand helfen. Hier der Link zur Diskussion: http://www.delphi-forum.de/topic_MSSQL+Fehler+bei+Gleitkommakonvertierung_92363,0.html

Answer 1

Vielleicht solltest Du mal einen Trace mitlaufen lassen und versuchen, dass nachzustellen. Der Trace hilft Dir zumindest dabei, zu überprüfen, was Ihr an den Server sendet zum Zeitpunkt des Fehlers. Irgendwie sieht diese Fehlermeldung nicht danach aus, als ob sie vom SQL Server kommt.

Falls Du Hilfe zum Trace brauchst, schau Dir das mal an: http://www.insidesql.org/beitraege/troubleshooting/serverbasierter-trace

---

-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org

Answer 2

Vielen Dank für den Link, das sieht recht viel versprechend aus.
Welche Events sollte ich denn deiner Meinung nach mitverfolgen?

Spontan würde ich

• Exception (33)
• SQL Transaction (50)
• Execution Warnings (67)
• Prepare SQL (71)
• Exec Prepared SQL (72)
• User Error Message (162)

einstellen. Sind das schon zuviele und wirken sich auf die Performance des Servers aus oder sollte ich vielleicht andere/mehr nehmen?
Bin für jeden Tipp dankbar.

Answer 3

Hallo Christoph,

könnte es sein das eure Gleitkommazahlen spezielle Werte wie Positive/Negative Infinity oder NaN enthalten?

Denn der SQL Server kann damit nicht umgehen, die Treiber reichen aber Fließkommazahlen häufig direkt durch.
Siehe auch http://groups.google.com/group/microsoft.public.de.sqlserver/msg/af88c0cf2284ab8d

Gruß Elmar

Answer 4

Ueblicherweise verfolge ich nur RPC:Completed & SQL:BatchCompleted, um die extra Last für den Server zu minimieren. Du solltest vielleicht damit mal anfangen. Hilfreich ist es auch, einen Filter auf die entsprechende Datenbank zu setzen oder direkt auf das Statement zu filtern und nicht alle Spalten auszuwählen. Die TextData Spalte sollte aber in jedem Fall ausgewählt werden, da dort das SQL-Statement gezeigt wird.

---

-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org

Answer 5

Nein, das kann ich ausschließen.
Wir übergeben nur Beträge, also auch nicht mehr als 2 Nachkommastellen - höchstens 3 bei einigen Prozentsätzen.

Answer 6

Die beiden werde ich mir dann mal genauer anschauen.

Das Problem ist, dass es nicht immer beim selben SQL auftritt, sondern an verschiedenen Stellen. Das Filtern auf ein SQL geht somit leider nicht.

Sporadisch bedeutet übrigens: Im April trat es auf und dann erst wieder im September.
Macht es Sinn den Trace über einen solchen Zeitraum laufen zu lassen?

Answer 7

Die beiden werde ich mir dann mal genauer anschauen.

Das Problem ist, dass es nicht immer beim selben SQL auftritt, sondern an verschiedenen Stellen. Das Filtern auf ein SQL geht somit leider nicht.

Sporadisch bedeutet übrigens: Im April trat es auf und dann erst wieder im September.
Macht es Sinn den Trace über einen solchen Zeitraum laufen zu lassen?

Hm, das ist natürlich SEHR sporadisch. :-)
Man kann einen Trace durchaus so lange laufen lassen. Nicht über den Profiler, sondern als "reinen" Server Trace und natürlich mit den erwähnten Filtern, um nicht unnötig viele Daten zu sammeln. Allerdings macht es vielleicht Sinn abhängig von der Priorität die diesem "Fehler" beigemessen wird, zu versuchen, dass Verhalten in einer Testumgebung nachzuvollziehen.

---

-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org

Answer 8

Hallo Christoph Schwerdtfeger,

Hat Dir die Antwort geholfen?

Grüße,
Robert

Answer 9

Ob mir die Antwort tatsächlich geholfen hat kann ich leider erst sagen, wenn das Problem erneut auftritt.
Wie bereits geschildert tritt das Problem sehr sporadisch auf (2x im Jahr). Momentan vermuten wir auch, dass das Problem nicht am SQL-Server, sondern an dem BDE-Treiber für dem SQL-Server liegt. Was es letztendlich ist und ob der Trace-Vorschlag hilft, weiß ich somit leider später - hoffentlich jedoch nicht erst in 6 Monaten...