the commit rollback thing

[ken white]

> > I think there is a basic understanding among multi-user programmers (you
> > obvously being included) that there _are_ simply some situations that
can
> > not be "covered". Any report is only as good as the absolutley
to-the-minute
> > data available. If someone changes a record micro/nanoseconds _after_
the
> > report has been generated... tough. right?
>
> Well, wrong.  And this is the difference between filePro and a (forgive
> me) 'real' DBMS:  Oracle, PostGres, Firebird, Interbase, any of the SQL
> DBMS engines will in fact guarantee that all the data is just like you
> left it.

John, the buzz word is repeatable read, which in short means that within a
transaction no matter how many times the data is read the values are the
same as when the transaction started.  When using repeatable reads
transactions from other users are cached and are not immediately posted.
When the transaction is committed ( or rolled back ) then other user
transactions are applied to the database.  Depending on the changes ( and
business rules ) which occured within the original transaction some of
deffered transactions may fail.

In filepro it is very easy to mimic inconsistent data

dreport foo -f post -a -v postsel -u

postsel selects a record based on some criteria
user 2 changes a record which postsel just selected.
dreport prc.post changes the modified record

To prevent this the selection criteria must be repeated in the processing
table "post" to validate that the record still passes the selection
criteria.  This is a pita if you use a single prc.post with many selection
processing tables.