I've rarely had table corruption myself with the exception of one client about 10 years ago- and they had it several times a day, everyday - thus having to kick out 400+ users several times a day to reindex tables (which is why I think they fired the guy and hired me to fix it). The fix was to use remote views. HUGE difference between having the ODBC driver open the table and VFP open the table. I don't know how the internals of VFP work - but I know that this fixed my clients problem.

Plus...what is the property change to switch local views to remote views and set the connection strings for them? I don't see an easy way to do that??? Unless I'm missing something here I don't see how this could be as easy as the 3 lines of code needed to switch the connection string like I have below.

>I have rarely had table corruption. Application design makes a bigger impact. I'm not sure I understand your issue with this. The tables have to be open either way. With VFP ODBC, the driver opens the tables. It's still the VFP data engine inside. It still gets opened from the workstation, not the server. It really isn't any difference.
>
>
>>Yes but using the local views causes VFP to open the tables - thus putting you at risk for what makes VFP not so great - possible table and index corruption. That alone makes using the remote views instead a better solution for me. Plus all you have to do is change a connection string to switch backends (assuming you designed all of your tables properly to begin with).
>>
>>So for me it's 3 lines of code to switch backends:
>>
>>llDataSourceSet = DBSETPROP('MyConnectionName', 'CONNECTION', 'DataSource', 'MyODBCname')
>>llUserIdSet = DBSETPROP('MyConnectionName', 'CONNECTION', 'UserID', 'MyUserID')
>>llPasswordSet = DBSETPROP('MyConnectionName', 'CONNECTION', 'PassWord', 'MyPassWord')
>>
>>
>>What is the property change to switch local views to remote views and set the connection strings for them?
>>