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

With my business classes you create the select statements by setting properties, and if a data conversion is necessary, its done by Access and Assign methods.