Hi!

There are really a lot of differences in syntax and functionality of queries between VFP and SQL. It might be terrible work if application is large.

We did something like that in the past. There are 2 approaches:

1. Use always views for all queries. Have 3 databases - VFP data database, VFP views, SQL Server remote views. When switching between SQL/VFP, just change database with views. Name all views the same way in SQL and VFP databases for views.

This approach might be troublesome, because VFP has built-in SELECT statement for read-only data that is very handy until working with native data, because no need in huge number of views. When you already have complete application and used views everywhere, this approach is very simple - just need to write analogue views for SQL.

One of the common problem also is VFP local views based on the table and another view, when converting them to SQL Server. This is not possible with SQL Server, or possible with very terrible speed. I hope you did not used views based on table and another veiw.

2. Have a table with all queries in your application - query name, SQL version of query (memo), VFP version of query (memo). Have a function named "QueryData" that will get query name and return query result by running appropriate query (dependent on what is selected as a backend).

This approach also might be used to re-generate views, if you use them. It is useful when creating new applicationf or working with both backends - existing application requires changes to work using this approach.

Finally, common problem is generating new unique ID values. I recommend to investigate this problem and make a solution before proceeding further.


>While researching what is involved to upsize/migrate our application to use a SQL Server back end, I recalled that that my colleague wanted to achieve having a single set of code that supported the use of either SQL or VFP as the data engine (depending on the client site). I think the reasoning for this is because we cannot anticipate all of our clients wanting to migrate to the SQL version at the same time.
>
>I was curious if anyone here has had experiences (be they good or bad) in the scenario described above. Are we looking for headaches?
>
>Any insight would be greatly appreciated.
>
>Laterness,
>Jon