>I have to jump in here and give my two cents on this.
>
>Yes, you can connect to VFP databases remotely via ODBC. The problem with using ODBC to connect to local VFP tables is that it is slow. VFP screams when using local data natively. That's why we all love it! That's why we went with dual code. That way for local systems you get the blazing speed we all know and love.
>
>Another consideration is that a SQL query that works in VFP may not work for a backend like SQLServer or ORACLE. One thing that caused us grief is GROUP BYs. VFP lets you have non-aggregate fields in the field list that are not included in the GROUP BY clause. Great for quick summaries of data. SQLServer and ORACLE do not allow this.
>
>Again, just my 2 cents
>
>>Hi Bret,
>>
>>Yes, this possible. The key is to not make use of local tables directly. Rather, connect to your local tables either through SQL passthrough or through remote views. Instead of using DSN's directly - use a connection object in your database. If your remote views point to a connection - all you have to do is change the connection string of the connection object. Whether your connection goes against one DSN or another is not a big deal. As long as table and field names are constant - you should be in good shape.
>>
>>HTH
>>
>>>Can a VFP application be developed to use an SQL server when networked, but when the exe is distributed use local tables. If this easy to accomplish or is this two separtate developments (network and distributed exe). I have someone here who believes that VFP can be switched SQL/NonSQL at run time. I have no experience with client server so I have never approached VFP but in the DBC/local tables concept. Any suggestions would be appreciated.

Thank you for your response and insight, I appreciate all responses from people who have been in the trenches with VFP and fighting these issues. Thank you again I am passing on all response to our team.