>Thank you, the problem is our plan was to have an App that DOES NOT need to know the DB schema to work,
>so the insert statements were planned to just post data to the DB and let the DB handle the trimming.
>That way the App is generic and works regardless of DB changes.
>
>My idea of recompiling the FB client was to "capture" any insert statement on the customers side, and
>replace it with a trimmed insert statement. I don't see an issue with that. I am not sure why you think
>it is not possible. Alternatively we could capture the insert statements on the server side, and
>replace the original insert with a trimmed sentence using the DB schema to know the size to use for
>each field. I was hopping to be able to resolve it without a re-compile of the DB engine, but it seems
>I was wrong.
>
>Regarding the DB doing it's job in checking and protecting against arithmetic overflow, I still think
>the way it is done is a Bug as it is actually checking the size of a field that is NOT what is being
>inserted because the trigger has actually changed already the size of the field to be inserted, so the
>DB is actually checking something that is irrelevant. I don't know if it was designed to be that way
>for a reason, or if it was something that could be "re-designed" to compare the field actually being
>inserted after all triggers have being applied. Under the current model, what would happened if we have
>a trigger before insert to update the field in a way that it does not feet any-more into the target
>table? The checking and validation was done before the trigger, so I guess it did not pick up the issue
>and who know what was actually inserted?

Hi Fabian!

I don't think telling the user that the field is too long to handle can be considered a bug. Sure, it would be nice if Firebird had infinitely sized buffers and didn't check the size until after the BEFORE INSERT trigger had finished, but it doesn't. First, Firebird receives data, then BEFORE triggers are executed, then the data is stored in the database. The error that you see occurs before the BEFORE INSERT trigger.

Your problem is still solvable. Simply add another table. Let one table have huge field lengths (CHAR/VARCHAR or BLOB SUBTYPE TEXT) and use this only for imports, then use AFTER INSERT triggers to copy the first few characters of field(s) to the other table (which you in turn use for querying). Variations of this solution includes adding another field rather than table or even another database ('another database' would probably be an overkill and more difficult to implement in triggers).

HTH,
Set