Helen 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? Regards, Fabian --- In firebird-support@yahoogroups.com, Helen Borrie wrote: > > At 02:28 p.m. 17/01/2013, fabianchocron wrote: > >> OLD/NEW pseudo-records have the same format as regular table > >> records, inheriting the same length limits. And this is not a bug. > > > >Hi Dmitry > > > >mmm, it does not make sanse to me, think it this way: > > > >The field on table is say char 32 > >The insert is trying to insert a string of 40 characters, say "AAA..." > >repeated 40 times > >What you are saying is the old and new records are char (32), and that is > >fine, as the trigger is assigning a string of say 31 characters into a char > >32. Why is it failing? > > It is failing for the reason explained by Dmitry and Ann: the NEW variable > has the same size as the column definition - in your example, char(32). > Therefore, there is no way to store a string of 40 characters in the NEW > variable. The exception occurs *before* the context variables are created, > do you see? > > > >the instruction on the trigger is: > > > >new.mychar = substring(new.mychar from 1 for 31) > > > >I don't see where the code is breaching the rules? > > OK, one more time. NEW.MYCHAR is defined by the size of the column named > MYCHAR in your table. Your substring expression cannot work because the > exception happens in the parsing of the dynamic value passed in the INSERT > statement. > > >Unless Firebird is comparing the size of the original string posted in the > >insert instruction against the database, and that to me sounds like a bug. > > > You think it is a bug if a database engine protects databases from string > overflow? Oh dear, dear, you need to take some deep breaths, methinks. > > Triggers work in database operations, not in the client. > > ./heLen >
