>>>>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.
>
>Both of these select statements are "wrong", unless you don't care about security. They should both read: SELECT * FROM billing where inv_date = ?ldDate.
>

These are literal constants.
Are literal constants insecure?