>Mark

>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.

>Cheers
>Fabian

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]