>> If I issue a statement like:
>>
>> INSERT INTO ATABLE (AFIELD, BFIELD)
>> VALUES ('A', 'B');
>>
>> And get an exception, what should be the state of the database?
>>
>> If we follow your advice and allow stored procedures to issue
>> commits (or even commit retaining) then the state is
>> indeterminate
> The state is not indeterminate, the rest of the process is
> still under a transaction.

Did I tell you where or what the exception was? How can you
possibly say that the state can be determined? Did the
exception occur before or after your internal commit? Unless
it is the most simple of examples how are you to know?

> You are acting like I'm trying to come up with a new way to
> handle databases, I'm not, it's already being done, and being
> done quiet well.

I am not saying its new. I am saying that would NOT like to
see it as part of FB. There are lots of examples where systems
try to help stop developers from shooting themselves in the
foot - there is even a long old joke about different ways to
shoot yourself in different programming languages.

> Also, what about those situations where it's OK to save part
> of the transaction if the other part fails.

> For example:
> A new customer purchases something from your store.

> You would send the new customer and purchasing document
> information to your Stored Procedure/middle tier...You would
> go ahead and commit the customer record first, because if
> the commiting of the document fails, you don't want to lose
> the customer information.

Your example shows me nothing that would not be better handled
by explicit transaction control.

If there are two transactions then treat it as two transactions.
If you have a middle tier then your may decide to use that to
manage your transactions.

> Just because you guys may not see a need for it doesn't mean
> it's not needed. If you don't need it, don't use it, but
> other databases have it because there is a need for it and
> it's very useful.

As I already explained, I can see the benefit in using stored
scripts - an object like a stored procedure that must manage
its own transactions (possibly even its own connections). Such
an object would give solutions to the needs you describe
without needing to encourage breaking of data integrity.

Do you see what I am getting at here? It is not that there is
a problem or argument with what you want to do. There is a
problem with your proposed solution. A better solution is
feasible and if any changes are to be made then the better
solution is the one we should aim for.

--
Geoff Worboys
Telesis Computing