>Hi Walter
>
>>>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?

No problems here using this logic. There are a few things you have to watch for (for example, datetime fields in remote views don't accept .null. values I think) - and if you want to do what I did and be able to switch to sql server just by changing the connection string you need to be sure your tables are compatible with sql server (again - datetime fields - dont use just date or just time...use datetime since that's what sql server does). The idea is really pretty slick - I'm suprised more people haven't come up with this concept.


>>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?
>
>>
>>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.

Yep this is what I did here too. On my current application - even though the tables are in one DBC - they're acutally scattered on 3 different hard-drives and servers, so I put all those locations in the pathing first.

>>
>>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.