RE: framework question

> From: CWilt@xxxxxxxxxxxx

Charles, you've made some excellent points and at the same time managed
to duck a few of the critical issues, although not without acknowledging
that they at least exist.

I think it's fair to say that you have made a reasoned point for
commitment control.  Although I still wonder about how much overhead is
implied when you allow multiple transactions against the same file, with
each transaction allowed locks of multiple records - my guess is that
during the locking you either have a lock array or a GIGANTIC bitmap
that identifies locked records, and either one is resource intensive,
though in different ways.


> Unless the system abends from external or internal causes.  Does it
happen
> often?  Nope.  But it does happen and it can be a real pain to recover
> from.
> If your data is critical then your data is critical.

I do want to address this point, though.  If you are using batched
transactions, then it's trivial to allow rollback on abend.  You simply
don't clear the transaction records until they're processed, and on an
abend you come back and roll back the changes.  Obviously its nowhere
near as simple if you have multiple ways to update the data, but that's
a different issue.

You mentioned the fact that if people can't access your data, then it
goes to SQL server.  That may be true for query, but I certainly don't
allow ODBC UPDATES to my database, no matter what.  You want that, yes
indeed you can move to SQL Server and then call me when your database
trashes.  No amount of commitment control is going to protect you from
Fat-Fingered Freddie in Accounting.

Joe