>Hi Gary,
>
>the oplocks comments are sound. As we found out when we deployed our app back in 2002.
>
>BUT -- when a file is over a certain size (seems like it was about 200MB), we found a slowness in opening that no amount of changing indexes, etc. fixed. And these openings were being done with NODATA. I looked at it with Filemon, advanced options, and what I saw was every record being scanned.

I've found that using CREATE CURSOR is much faster than NODATA with complex SQL and even faster than asking a remote database for an empty structure.

>That's a function of using SMB. Put the same app on a Terminal Server with the data on the server and the problem goes away.
>
>That, and file sizes, drove us to SQL Server (same app -- we wrote it with views anticipating the need).
>
>Hank
>
>>I have been investigating a site that is showing poor performance on data read/write, but basically whole system does not perform well.
>>
>>EXE is local to workstation as are all graphics files and virtually everything other than DBC/DBF etc., server is 2003 SBS, SMB2 is disabled, current workstation I am testing is Vista but issue is also present on Windows 7 pcs. All data is loaded using SELECT sql commands into cursors NOFILTER (temp folder is on local workstation).
>>
>>What I have discoverred today is that if I set up side by side installs, one to the "Live" data being accessed by 15 or so users, and one to a test data folder (on save server, same drive) my test data loads significantly faster.
>>
>>Is there a server setting limiting folder access? I thought VFP tables had no access limits? there should be no record locking going on as this is simply a data load at this point.
>>
>>Any ideas what could cause this?
>>
>>Gary.