>>For many years I worked with VFP based software produced by a major manufacturer (nameless here but with some imagination you can figure the name)
>>Faced with the same choice, they chose your option - one code base for two back ends.
>>The result was a disaster.
>>Maintenance classes - CRUD - were OK - they used classes as Tore suggested - but the reporting procedures were nightmares. Since the queries had to conform to two backends, neither was well supported. In many cases they wound up writing two versions.
>>We supported the code and it was painful just to look at it.
>>Several people involved told me that in retrospect, they should have produced a VFP/SQL Server only product to run side by side with the .dbf product.
>>This might not be relevant in your situation, but it's something to consider.
>
>Any example of query that would not work both ways?
>

Here's a trivial example.

VFP
SELECT * FROM billing WHERE inv_date = {01/31/17}

SQL Server
SELECT * FROM billing where inv_date = '2017-01-31'

Yes, there are ways to handle that, but they add no inherent value.


The advanced features available in recent versions of SQL Server and not available in VFP queries are too numerous to mention.

>Which data access technique did they use? cursor adapter, views or SQL pass-through?
The wrote a hybrid thing that ultimately used SQL pass-through.