|Subject||RE: [firebird-support] Re: Issues with String Truncation error on insert (FB 2.1 64 bits windows server)|
>Markexception but you have to admit from the high level perspective it sounds
>Thank you, I understand the need for the DB to return to the requester the
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 developersmeeting and a solution would be found.
>If you think it breaking the problem by level, it is easier to see theissue, let's think it this way:
>1) Level Requester, where the insert statement is created, or App.the data saving process.
>2) Level Massaging where the triggers occur before being ready to pass to
>3) Level Archiving, where the DB validates and either saves or returnserror to requester.
>The key is understanding that in 1) and 2) there is still "changeoccurring" 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.
I would go with stored procedure with input parameter 32K. Inside stored
procedure, you can do whatever you want.
Or am i missing something ?
[Non-text portions of this message have been removed]