>- I will have to reengineer some forms to just pull down way less data (currently their company table has approx 7000 records and the form allows them to search a browsable list) and this is not a big deal. I understand though that I will most likely need to change something like this to bring down a subset of records; it would give me the possibility to present design concepts to them on a lesser used form to approve and they could see the performance

The old lore for such cases make two views. One full and narrow, one very low (single record) but with everything in it, full width. It's either "gimme these ten columns for all the rows" or "gimme all columns for this one row". You surely don't need to bring down the customer's secretary's phone number, number of late payments in last ten years, CEO's middle name etc when you need a lookup to search through.

>- rewriting an entire large app myself over a couple of years and then migrating to it in one jump is full of pitfalls - we all know how many bugs can be found even with the best of testing; I could develop my own framework and perfect it before rolling it out to all the screens.

>So say I change my app to use the cursoradaptor class - does this allow some calls to be made to the SQL backend and others to just access the local/server VFP tables?

What we had in the current project was similar but never really forcing anyone to drive right, we had SQL as an option, and everything could be done in both dbfs and SQL, but not mixed. True, that was made before my time, but I remember a few years when both were in production. There's a difference in the SQL language between Fox and anything else - you'd have to translate every .t. into 1=1 and .f. into 0=1, every nvl() into isnull(), icase() into case when ... else ... end, every date constant into a date constant string, alltrim() into ltrim(rtrim()) etc. There are about 20 or so differences of the kind. And, ah, ending the line with a semicolon has exactly the opposite meaning.

This was resolved by having the SQL statements in a dbf, with as much automatic translation as possible. For the few where translation would be too hard to convert programmatically, we had two versions of those - one for dbfs, one for SQL. And then one day we decided to just drop support for dbfs and never looked back.