Jochem Maas wrote:

> I don't consider what I built as re-inventing the wheel. I also think (in far as I
> can tell from your description) that my implementation is technically better than the adoDB
> implementation (granted that the adoDB implementation is generic andf mine is bound to
> a specific table in my DB) because mine garantees atomicity where as the adoDB one
> does not (it can't given that it's a 2 stage process that occur in different places, namely
> inside the firebird process and inside the php process).

It is just a different approach to a similar problem. As always there
are many ways of doing the same thing. ADOdb has three different methods
of doing this, and yes it is database agnostic.

> for instance what happens if you succesfully create the generator then the insert fails?
> then you have to remove the generator, right? what if that fails? - I'd rather
> let firebird sort that out.

Actually the bitweaver approach would establish the next 'prizedraw'
number, create an entry for that, create the matching generator and any
other secondary table entries to go with that, and THEN commit the data.
Rolling back if a problem prevents any stage. In the early days I had a
problem preventing code working because Firebird WAS rolling back
properly - I just did not know it :(

You have posted to the php list, but actually your 'discussion' is
really one for support, since there is actually no php involved anyway ;)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.