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