Subject Re: [Firebird-Architect] Another Model for Database Events
Author Jim Starkey
Alexander Peshkoff wrote:
> On Monday 15 March 2010 22:58:41 Jim Starkey wrote:
>> The basic idea that internal update operation check for declared
>> events. For each declared event, it evaluates the fields in the field
>> list for the before and after record versions, as appropriate.
> I've implemented more or less same approach on top of DBF format around 13
> years ago. The main need in it was to have a kind of RI in DBFs. It passed
> all required tests, but did not go into production because the company which
> wanted it and paid for it was first too lazy to use it, and later started to
> use SQL servers.
> Question - is there some handling of inserts and deletes? I've treated it as
> changing from NULL to SomeValue for inserts and on the contrary for deletes.
> It was pretty well for RI.
The getEventType() method will tell you whether it was an insert,
update, or delete. Or further down the road, maybe something else.

I haven't quite decided on what to do if somebody asks for a "before"
value for an insert or an "after" value for a delete. Probably throw an
>> It would be difficult but not impossible to implement with classic and
>> straightforward to superserver.
> Not too difficult - just one more shared memory object.
I'm allergic to shared memory. It tends to be limited by a kernel
parameter, the API is klunky, and is always a security and reliability

Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376

[Non-text portions of this message have been removed]