Hi doug,

>>After I marked the database readonly the same view was loaded in 0.20 seconds. It makes sense that it should be faster since the database can be cached in the workstation, though I was stunned in the performance difference.

>I bet it isn't caching (or at least not entirely), but rather locking. As Cindy mentioned, VFP locks the view records in the DBC every time you open the view; in a read-only DBC, I'm guessing it doesn't bother doing that since the view definition can't change.

Well, I thought the locking contention problem only occurred when dealing with remote data. In my case, it was just local data. However, I can imagine this would apply to local views as well since they are simular to remote views. Anyways, locking seems not to be the most logical cause in my case. Simple local views with a smal number of fields seems to load much faster than complex ones with a large number of fields, so the must be much more than only locking the view definition record.

>>My question is, has someone found problems or bugs when using readonly databases ?
>
>Assuming you're not using offline view (which would need a writable DBC), the only thing I can think of that could possibly be an issue is transactions. I haven't tested this, so it might not be an issue at all, but I think the DBC is used to temporarily store information while a transaction is in progress. It might be that the information is actually stored in an in-memory cache of the DBC rather than the physical file on disk, so, as I said, this may not be an issue at all.

I thought about that one too, but at least I saw that BEGIN - and END TRANSACTION and ROLLBACK seem not to raise any errors when the database is readonly. However I did not investigate if they work correctly.

Thanks for your feedback,

Walter,