>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

Thank you, John.