One other thing you could do to ease the pain.

I wrote a PRG that examines a form's DE and creates a listing of code to open all the data, set relationships
and set up buffering based off the objects in the data environment.

You could do something similar to convert DE objects to point to your data access class. Then simply run
the PRG with the name of the form, and remove all DE objects, and the code into the Load event.

I can supply the code if you'de like.




>We are considering a conversion of a large VFP 8 application from native VFP databases to use an SQL server based back-end.
>
>The application opens tables via USE and via form data environment. It uses SEEKS, LOCATES, REPLACES, etc. on the tables and TABLEUPDATE to update the tables.
>
>We would have to move the data structures over to a SQL backend, then update the code to access the new database. There is a lot of business logic in the vfp source code (do whiles with replaces, etc.)
>
>I realize there are books from Hentzenwerke that discuss using MySQL with VFP, and we will be looking at them. We also have West-wind and their business objects, which look good. However, to use them requires your app be designed up-front for them. Or re-written to use them.
>
>1. Has anyone actually performed such a conversion on a large VFP application? (606 forms, 296 prgs, 178 report files) I'd like to talk to you if you have.
>
>2. Are there any drop-in replacements for USE/SEEK/REPLACE, that translate them to SQL on the backend. It seems technically possible to create a USEsql(), SEEKsql(), etc. that you could use in place of the native function calls that would get to 80% of the way to an SQL backend without having to refactor all your business logic. Has anyone seen anything like this?
>
>Thanks for your help,
>Chris