Dmitry,

I'd advise always using parameterized queries:

MYTABLE.DATE_FLD >=?dDateValue

This works in VFP, but also if you upsize to remote databases like SQL Server or Oracle that expect different date strings from VFP if you concatenate. There's 2 other advantages:

- Against SQL Server, parameterized queries are cached so that subsequent calls are as efficient as a SP, and

- Paramrterized queries are immune to SQL Injection. This isn't a risk in your date example but is a serious risk if you're concatenating string parameters. For anybody who hasn't encountered this:

E.g. app has lots of customers of different salespeople. Salesperson logs in and can look up only their own customers:

lcloggedinsalesperson="dlitvak'
lcSQL=[select * from customers where salesperson=']+m.lcloggedinsalesperson+[' and cust_code=']+m.lcUserinput+[']

Which limits searches to your own customers... unless a hacker enters a customer code like

' or cust_code like '%

And then the query is concatenated:

select * from customers where salesperson='dlitvak' and cust_code='' or cust_code like '%'

and now the hacker browses the entire customer list. In remote databases, injection has been used destructively by hackers and annoyed ex-employees- e.g. hacker enters

';drop table customers--

select * from customers where salesperson='dlitvak' and cust_code='' ; drop table customers--

and now there's no customers table.

In contrast, this is immune to the problem:

select * from customers where salesperson=?lcloggedinsalesperson and cust_code=?lcuserinput