>>>If you use the defaults of SS, yes this is true. The default of SS (at least 2000) is READ COMMITED. However, for simple querying, I change the transaction isolation level to READ UNCOMMITED. Then no locking interferes. This makes SS act the same as VFP. Only those mods commited to disk are read.
>>
>>So you are using durty reads that means that the data that you are getting doesn't mean that will be the real data this can be dangerous.
>
>True. But usually with a query, I want a snapshot. This gives me a snapshot. Whether the user is going to rollback the changes or even change them again is irrelevant to me at this point. I could be running a summary report and I don't want the fact that some user is updating a row (or series of rows) to effect the manager's ability to run a snapshot report. If the manager wants "real" data, taht is factor to take into account and the appropriate settinsg can be changed at that time. However, that is the "norm" in this case.
>
>And I want to clear up something I posted earlier. READ UNCOMMITED makes SS bahave like VFP in that reads do nothing to the table. No locking is done; only a read is performed. However, it differs in that mods (whether commited or not) are also read. Changes that are in limbo can also be read by SS.

Also new records delete records you name it.