>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?

Ours was from a Web site environment. But, the criterias were pretty much the same. The first thing we did was to go through VFPOleDb as we moved the application from VFP to ASP.NET. So, we standardized all data access to go through one of those four methods:

SQLExec()
SQLUpdate()
SQLDelete()
SQLInsert()

which are included in our data provider class.

Then, the next process was to make those SQL commands to be ANSI SQL compliant.

After that, the data was migrated to SQL Server, at first from a test environment, the only think needed is to change the connection string to hit the SQLClient provider.

We are talking about 120 tables, 2500 fields, 1200 indexes and about 150 ASPX pages. We have some tables with millions of records. So, the challenges were pretty high and proceeding one step at a time seemed to be the way to go.

So, basically, everything that is native to VFP, such as USE, SEEK, REPLACE, this is all gone. We had to think ANSI SQL compliant with the ability to switch backend at any time, with minimal adjustments in the framework, if necessary.