not disputing, but I see it in a different light:

between 40 and 70% can run unchanged (with some consideration before on how to handle things like .t./.f. and dates)
between 25 and 50% can run with automatically generated/altered syntax
between 5 and 20% really needs manual effort

The RV approach runs into the trouble of maintainance which can and should be automated as you did -
but IMO that shows the weak spot of the RV/DBC approach.
Working with a class based approach building the SQL at least for me makes it easier
to code just the differences. Strategies or hooks to the rescue...

Craig and others mentioned subobtimal speed if not written to each engine:
yes, that can and will happen. But as my addition to each framework was a logging setup,
which was also introduced to the code calling back into data, such differences were found early
by comparing the times in each log or the aggregated "data times" for specific situations.

Now tickling the primadonna side of the specific backend developer produced better speed overall -
only difficulty was agreeing on what speed benefit was reason enough for a code change adding to
different behaviour or perhaps changing it upstream in the code hierarchy resulting in
different percent changes in some backends. Fun days...

my 0.02€

thomas

>Ultimately remote views are just wrappers for SPT. If the syntax works, the view works. There are enough syntactic differences between the VFP and TSQL versions of SQL that it is easy to blow it up. Example: you can do a view of view in VFP. SQL hates that. I have a whole list of them someplace as I was doing so many conversions of VFE projects ( where I had taught everyone to always use remote views and never code against tables ) that I wrote a program to analyze views designed to work against DBCs and find those things that weren't going to work against SQL. That was all it took, thanks to Mike and Toni's brilliant design of the framework itself, which really loved SQL Server. We always taught keeping views in their own DBC, so once you had created a views DBC tailored for SQL you actually could run the same app against either VFP or SQL data, but the views DBC had to be crafted for the backend.
>
>A big difference, in practice though, was that it was easier to use GUIDs for pks since you could generate them for new records ( and hence populate fks in children ) on the front end. That was fine (even before sequential uids were introduced in SQL) for smaller apps where index insert speed and table size wasn't a huge deal. But most existing SQL databases would employ identity keys, so we had some magic in our datalayer to handle syncing the newly generated parent pks with the fks in the new children when there was a big save of a new parent and multiple child table records at one time. So a lot of times the "upsizing" would include rethinking pk / fks
>
>In my big project rescue job at Dow Jones this was a very big deal, as the tables were quite large and the existing app was doing some stuff that was ... creative - but stupid :-)