>
> Arrrghhh!! It would be a crazy, terrible design to make execution
> decisions by parsing error text! What if the error text got

changed by

> some minor corrective surgery in a sub-release (this happens!!)

What if

> the firebird.msg file is not in English? The API shelters you

from this

> sort of craziness.

No, u don't understand. In the called SP i only respond to things
that i want to log. It contains alot of updates that can succeed or
fail. In my main procedure i only eat up my own custom made
exceptions 'INVALID_ENTRY', 'LOCKED_ENTRY' ... and log them with
their own given CUSTOM messagetext when they were raised. I use the
messagetext to get the PK from the table where the excpetion
occurred logged. So after the whole procedure is completed. When its
returned to the client side with an exception, it wasn't 1 of mine i
logged and rollback the transaction. If it succeeded without
exception if the log is empty all updates where done, if not i'll
have a list of the rows where some exception occurred and the pk of
the table that caused it. So i can show detailed info at the
clientside what went wrong and why.

Greetings,
Filip Moons


SP2
...
If some_invalid_entry then
exception 'INVALID_ENTRY' 'TABLENAME:'||Cast(PK as VARCHAR(9));
...

begin
UPDATE MYTABLE SET.... WHERE MYPK = ...
WHEN GDSCODE DeadLock, GDSCODE lock_conflict DO
exception 'LOCKED_ENTRY' 'MYTABLE:'||Cast(MYPK as VARCHAR(9));
end

SP1

EXECUTE PROCEDURE SP2
WHEN EXCEPTION INVALID_ENTRY DO
BEGIN
ERRORCOUNT = ERRORCOUNT + 1;
INSERT INTO TMPLOG
(...,TMPLOEXCEPTION_NAME,TMPLOEXCEPTION_MSG)
VALUES
(...,'INVALID_ENTRY','TABLENAME;'||CAST(ID as VARCHAR(9))); <---

WHEN EXCEPTION LOCKED_ENTRY DO
BEGIN
ERRORCOUNT = ERRORCOUNT + 1;
INSERT INTO TMPLOG
(...,TMPLOEXCEPTION_NAME,TMPLOEXCEPTION_MSG)
VALUES
(...,'INVALID_ENTRY','TABLENAME;'||CAST(ID as VARCHAR(9))); <---

END