>PMFJI -
>
>I came from the YAG Codebook tree and VFE began there in its approach to using remote views. We believed at one time that with lv_ and rv_ and the stuff we had in the framework we had acheived "all you gotta do is" for switching from local ( against VFP tables ) views to remote ( SQL database ) views. Our cursors would work against v_ remote views and with the flip of a switch we could go from local to remote. Great theory and in fact with three lines of code we could have the views look at VFP data or SQL data quite easily. And in carefully crafted demos it looked really cool, like the stuff one dazzles crowds with in "all you gotta do" demos at conferences. ( remember just dragging a table onto a VFP form and having the audience go "Ooooh" :-)
>
>Spent the last 10 years of my VFP development doing all my own development against SQL databases and mentoring a lot of projects and doing a lot of conversions of DBC/DBF projects to SQL Server and I never saw a case where anything but the simplest remote views worked against either backend. Syntax just too different for anything beyond very basic stuff. Typically out of 200 remote views written against VFP tables I could use 30-50 without syntax changes. Yes, two different views DBCs - one for VFP and one for SQL could work but I just never was able to get around some very basic stuff about VFP vs TSQL remote view syntax.
>
>Have you really figured out how to get around this? When you say you can switch to any backend with three lines of code you are describing something I never saw in practice.

I have great pleasure to agree with you for a change :))
Long time ago (back in late 90ies ) I worked for a small shop (as newcomer) which bought up on this idea. So it was remote views hitting back-end databases via ODBC. (Vfp(6) DBC / MSSQL 6.5 i believe).
In theory you should change only data source, and everything should just work right ?
In reality we were having crappy performance for 95% of customers (accessing DBC via ODBC) and acceptable at best for those who opted for MSSQL. I will never forget SHAME of going to customer sites and having to make excuses (to something I had no fault of my own) and watching them suffer on extremely slow application.

Since that time I completely abandoned that as idea, and wrote clean framework geared towards networked app with shared DBC
(blazingly fast, with buffering/transactions etc) and another one (of shoot) for true Client-Server scenario with remote views etc. To this day I believe these two should be never mixed into one. There is no 'unisex' solution. Period.

Yes, it does mean you have to maintain two versions of source code at all times, but at least you give all your users maximum in both scenarios.