To expand a littlle on what Trey said, VFP stops comparisons after it has completely scanned the string/value on the right side of the equation. In this instance, it stops comparing after 0 comparisons. Since the default is to start out equal, the empty string is equivalent to everything.

In order to stop the default behavior of VFP, you have to set EXACT ON or use the == operator. This makes VFP default to things are not equal until it proves they are.

However, that may mess some other things up (or you could invoke the C5 gods ;-)) so you need to use a value that is not in your table. Trey suggested a space. This could work but if for some reason you have an entry with the first character a space (for whatever reason), you will get that record and not an empty set. What I sometimes do, is use a string that is longer than the target string. You could use replicate(" ",len(tartgetstring)+1). This way you know the value will never be equal unless MS changes the way they compare strings.

HTH.

>Alright! I know this question has probably been asked before but I'll ask it again...
>
>Here's my SQL Statement(either one gives the same results):
>
>Select * from customer where cCustName = ?vp_CustName
>
>Select * from customer where cCustName like ?vp_CustName
>
>If I execute this statement on a local vfp or fp table I get a dialog box just as expected. If I enter a value to populate the view parameter I get a set of records - just as expected. But, if I leave the view parameter empty shouldn't I get an empty record set? NO! I get the whole stinking table in my record set.
>
>However, If I perform either one of these queries throught ODBC and I leave the view parameter empty I get just as I expect - an empty record set.
>
>How can I get VFP 6.0 to treat a select statment as if it's running on ODBC? Or is this normal behavior and I should just shut-up, bite the bullet and code to this behavior?