>I've done exactly what you're looking to do. One of my clients markets an application that was originally written for native VFP data and now supports either VFP or SQL Server. I used local views for any data that would be updated and SELECT statements for ad-hoc queries. When the user chooses a record to edit, that record is brought down in a view filtered on the primary key. This is quite fast. I wrote a function that handles sending a SQL command either to VFP or SQL Server. If the backend is VFP the command is run with macro substitution, if it's SQL Server the function sends the query to the server using SQL pass-through. I think the combination of views and pass-through is ideal because it makes updating data easy (use views) and ad-hoc querying easy (pass-through). There is some conditional code that checks which back end is in use, but it's almost completely a single code base.
>
>Just my $.02
>


Hi Josh,
I am in the process of converting my VFP app to also run SQL Server. It looks like I have a simular strategy. Glad to hear I'm not alone!<g> The function I wrote to handle SPT handles quotes ok and I've just discovered I need to convert .T. and .F. Any other gotchas you're willing to share?

Also, when I tried to add a record for the first time via a Remote View, I got an error that a field doesn't accept NULLs. Do I need to have Defaults set up on all the fields in the view? Or am I missing something else?

TIA,
Bill