[Firebird] "arithmetic exception, numeric overflow, or string truncation"

// So sieht meine Tabellenstruktur aus (Hab einfach mal c# source kopiert)
db_create = "CREATE TABLE buggytable ";
			db_create += "(";
			db_create += "a INTEGER NOT NULL, ";
			db_create += "b INTEGER default '-1', ";
			db_create += "c varchar(50) default '', ";
			db_create += "d varchar(250) default '', ";
			db_create += "e varchar(200) default '', ";
			db_create += "f BLOB SUB_TYPE TEXT default '', ";
			db_create += "g BLOB SUB_TYPE TEXT default '', ";
			db_create += "h varchar(150) default 'Stück', ";
			db_create += "i varchar(150) default '', ";
			db_create += "j FLOAT default '0.0', ";
			db_create += "k FLOAT default '0.0', ";
			db_create += "m FLOAT default '0.0', ";
			db_create += "n BLOB SUB_TYPE TEXT default '', ";
			db_create += "o varchar(6) default 'nein', ";
			db_create += "p FLOAT default '0.0', ";
			db_create += "q FLOAT default '0.0', ";
			db_create += "v INTEGER default '16.0', ";
			db_create += "w INTEGER default '0', ";
			db_create += "x INTEGER default '0', ";
			db_create += "y INTEGER default '-1', ";
			db_create += "z INTEGER default '0', ";
			db_create += "PRIMARY KEY(a)";
			db_create += ");";

...und bei dieser SQL-Query:

bugQuery = "SELECT c, e, f AS headline, h, i, ";
			bugQuery += "o, p, q, n, v, m, j, k, ";
			bugQuery += "b FROM buggytable WHERE (c LIKE @findText OR h ";
			bugQuery += "LIKE @findText OR i LIKE @findText OR e LIKE @findText OR ";
			bugQuery += "f LIKE @findText)  AND y=0 ORDER BY c ASC;";

...gibbet die "arithmetic exception, numeric overflow, or string truncation" exception bei einigen Strings wenn findText z.B. ""ULTRAVIOLET MAN ASL 100ML" wäre. Lasse ich 100ML und die Leerzeichen weg klappt es. Das ganze scheint irgendwas mit der String-Länge zu tun zu haben.

Was mache ich falsch ?

Glaube ich nicht!

Kann es sein, daß Firebird nicht implizit von varchar in BLOB SUB_TYPE TEXT umwandeln kann, zumindest nicht, wenn Leerzeichen und / oder Zahlen darin vorkommen?

Teste das mal, indem Du die Prüfung auf f aus der Where-Bedingung rausschmeißt.

Mist, du hast Recht! Danke schonmal

Ich hab gerade in der Doku gelesen:
"Blobs can't be indexed, and access via search is limited to LIKE, STARTING and CONTAINING, also blobs cannot be compared using =, <,>, etc whilst varchars do support =, <.>, BETWEEN, IN as well as case sensitive LIKE and STARTING and case insensitive containing."

Hmm, gibts nen alternativen Datentyp (UPPER() und LIKE brauche ich da) ?
In nen varchar passen laut doku "nur" 32K und ich brauch ein wenig mehr
Oder was kann ich da machen ?

(Ich benutze übrigens den Firebird ADO.NET 2.0 Provider...)

Soweit ich das sehe, brauchst Du TEXT oder nTEXT (so der Datentyp in MS-SQL-Server). Derartige Felder enthalten ewig lange Texte.

Die eigentliche Frage dahinter ist, warum mußt Du darin suchen.

Oft läßt sich das umgehen, indem der Datensatz schon bei Anlage klassifiziert wird, und statt des Vergleichs der TEXT-Spalte, die Spalte Klassifikation ausgewertet wird (die einen oder mehrere Marker enthält).

[Firebird] &quot;arithmetic exception, numeric overflow, or string truncation&quot;

[Firebird] "arithmetic exception, numeric overflow, or string truncation"