Subject RE: [firebird-support] Re: Issues with String Truncation error on insert (FB 2.1 64 bits windows server)
Author Bogdan

>Thank you, I understand the need for the DB to return to the requester the
exception but you have to admit from the high level perspective it sounds
ridiculous to report an error on >data that has not yet being "prepared" by
the triggers. After all what's the logic in validating raw data when we know
there are triggers waiting to massage the data before posting it >to the
engine? Even if the raw data is valid, the triggers could then modify it and
make it "non-compliant" so from the high level point of view it seems the
validation process is not >efficient, it is effective but is checks things
before there are ready. Now from the Firebird's developer perspective, I do
understand 100% they need to allocate the memory for a >variable and that
variable needs to be inherited from somewhere.
>Perhaps in the future this issue will come to a head in some developers
meeting and a solution would be found.

>If you think it breaking the problem by level, it is easier to see the
issue, let's think it this way:
>1) Level Requester, where the insert statement is created, or App.
>2) Level Massaging where the triggers occur before being ready to pass to
the data saving process.
>3) Level Archiving, where the DB validates and either saves or returns
error to requester.

>The key is understanding that in 1) and 2) there is still "change
occurring" while 3) is a black or white outcome, where either the request
can be inserted or it is "illegal" and fails. At >the moment the DB is
returning an error on a request that has being posted by 1) but not being
processed by 2), so it seems inefficient to report on an issue before
allowing 2) to take >care of it.


Hi Fabian

I would go with stored procedure with input parameter 32K. Inside stored
procedure, you can do whatever you want.

Or am i missing something ?

Regards Bogdan

[Non-text portions of this message have been removed]