>>>>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?
>
>Yes and no. In your case, 2-digit date with ambiguous layout, hmmm... But that's constants, and hey, how many fixed dates do you have in your code? And how many times do you have a date variable? So if you do textmerge to insert the values, ah - you're setting yourself for SQL insertion. Just imagine someone being clever enough to have a "02/02/02' ; drop table customers; --" as the date value, and you merge that.
>
>When you're using embedded parameters, prefixed by question mark, the text is not merged into the command, but rather into a call to a stored procedure... sort of like this:
>
>select * from customers where lastpurchase>?ldDate
>
>becomes (something like this... too much hassle to bring up the profiler to catch actual syntax)
>
>exec sp_executesql 'select * from customers where lastpurchase>@P1','datetime', '2017-02-08'
>
>The 2nd and 3rd parameters become lists in case there were more of them. This way, the contents of the variable can be anything; if not a proper date, well, it will either cause an error or bring zero results - but won't drop any tables or do other mayhem.

You're making my point.
Look at how much time we spent on this.
If it had been one platform, it would have been a snap.