--- In firebird-support@yahoogroups.com, "Bogdan" wrote:

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

Hi,

If he can use stored procedure then i believe better is to change client side logic

i understand him previously that customer provide him whole insert statement and changing something now in application logic is problematic

with helper table and trigger (as i previously posted) this is simple to fix on db side

Regards,
Karol Bieniaszewski