Hi Karol

THANK YOU VERY VERY MUCH - Muchas Gracias !!!! Obrigado!

We are going to apply this solution you suggested, we need to do so for every field in the protocol so it will be a bit more generic and complex, but the concept is what matters, and this also shows that thinking outside the box is the key.

Cheers,
Fabian

--- In firebird-support@yahoogroups.com, "karolbieniaszewski" wrote:
>
>
>
> --- In firebird-support@yahoogroups.com, "fabianchocron" 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
> >
>
>
> I have a good mood today so here is a solution to your problem ;-)
>
> CREATE TABLE REAL_TABLE
> (
> REAL_FIELD VARCHAR(60)
> );
>
> CREATE TABLE AAA
> (
> XXX BLOB SUB_TYPE TEXT
> );
>
> CREATE TRIGGER TRIG_BI_AAA FOR AAA
> ACTIVE BEFORE INSERT POSITION 0
> AS
> BEGIN
> INSERT INTO REAL_TABLE(REAL_FIELD) VALUES(SUBSTRING(NEW.XXX FROM 1 FOR 60));
> NEW.BLOB = NULL;
> DELETE FROM AAA;
> END;
>
>
> Regards,
> Karol Bieniaszewski
>