--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:

> > ----
> > IF (NEW.ID IS NULL) THEN BEGIN
> >
> > genname = 'GEN_MASTER_' || new.type;
> >
> > update my$gen set val = val + 1 where name=:genname; /* locks
> > record, if any */
> >
> > select val from my$gen where name=:genname into :num;
> > if (num is null) then begin /* no such counter exists */
> > insert into my$gen values(:genname, 1);
> > num = 1;
> > end
> > new.id= :num;
> >
> > END
> > ----
> >
> > That, and CachingUpdates works as I initialy thought - Thanks
> > everyone, I learned much in the process :)
>
> Wow - Using DML on system tables and re-setting generator values

from the

Umm, I'm not using any system tables. The table my$gen is my own, i
used '$' sign as a pun.

> client - what a recipe for disaster in a multi-user environment!

Good luck.

All the 'generating' work is done in that trigger up there, the
clients don't touch the thing. And it is done in such a way to
facilitate multi-user inserts. I'm using deliberate deadlocks (all
clients have transactions in wait state) to ensure generator
correctnes, and more: if a transaction fails, generator IDs will not
get lost (the whole transaction, including the updating of my$gen
will be rolled back). All inserts will be "burst" in a short time
because of CachedUpdating property, so the whole thing should work
very well (and it is done similary in the example paper you sent me).

> But believe me - you'll be back - you're going to have lots of

problems now.

Honestly I do't see any - would you point some of them out to me?