Hi Mike,

>>>While I see your reasoning for the remote views, you are probably taking a performance hit versus local views, no?

>>Why do you think that? My experience is that the remote view is (far) faster than the local view if the local view is using dbfs on a remote drive.

>Would using remote views to access local VFP tables via ODBC as opposed to local views accessing local VFP tables without ODBC not cause a problem?

I'm not sure why you want to that. I was assuming that with remote views, we were talking about connecting to SQL server or oracle so that network traffic is reduced. There would not be any significant difference between opening VFP through ODBC or natively if you'd ask me, as the data is still processed locally.

>>There are also a few tricks to speed up your local views:

>>1. Don't use the Database! prefix in the FROM and join clauses. It will force VFP to open the table again (on OS level), where as the variant without the Database! prefix will use the already open alias.

>That sounds right. Do you have some proof?

Well use Filemon and do a SELECT * FROM MyDatabase!Mytable a couple of times and compare this with SELECT * FROM MyTable. You'll see the difference.

>>2. Be aware that you don't use a lot of SET PATH settings. Under a lot of circumstances VFP will search through all path settings (e.g. opening views) to search for a file. This might take significant time, esspecially on slower networks.

>Actually, you can get around that by having the data folder be the first thing in an otherwise very long path.

Ehh, I wish that were true. Sad thing is that if you do a USE MyDatabase!MyView, VFP first searches the path and only then come to the conclusion it is a view. If you've got a long path setting it is going through all of them. Which can be quite time consuming. Studing the behaviour with filemon will show you the details.

>>3. Use Filemon from www.sysinternals.com, to figure out what VFP is dragging accross the network and why. Really this could boost up your performance with local data significantly.

>Yes filemon is good stuff.