>>>>>>Using macro substitution inside a query is a bad idea anyway because it forces SQL to evaluate the macro for every row, and slows the query dramatically. HTH
>>>>>
>>>>>Erik, are you sure about this? If yes, then try some quick test.
>>>>>Actually, this is UDF which might be evaluated for each row.
>>>>
>>>>Ed, Thanks, but how can I look at the SQL statement while it is running? I know this isn't the best way to use SQL, but this way give the user more flexablity.
>>>
>>>Here, I have to ask you. What do you mean saying 'look at the SQL'. Surely, you can bring SQL command syntax into some Editbox that a user can view it. Is it what you are looking for?
>>
>>I am converting some pl/1 report programs to VFP 5.0 which use many different variables. I have put made methods that read a lookup table where most of the variables are stored. I want to be able to see the result of the methods in the select statement. I am not getting the results I expect, I want to see what is in the select statement.
>>
>>Or maybe, is there a better way to debug this problem.
>
>Sorry, I still don't understand. If you create SQL-command in code, you could use Debug Window, or messagebox, etc. Why are you not comfortable with this?

I have been using the Debug window and the messagebox. My problem was with "INLIST". The variables to the INLIST commands are in a lookup-table. The substitution wasn't passing variables as I thought. I fixed the problem by adding another "&" in front of the variables in the INLIST.

var2 = '01', '02'
var4 = '44','55'

cSelect = select var1, iif(inlist(code,var2),'good','bad') tmp code,var3 from xxx where !inlist(code,var4)
&cSelect

I got it to work this way:


cSelect = select var1, iif(inlist,&var2) tmp code,var3 from xxx where !inlist(code,&var4)
&cSelect