Hi Jim (and all),

I have gone at this numerous ways, including BROWSing, step-tracing, the works. I appreciate all the suggestions, and have tried many of them, but to nowhere. I've had to re-write the thing because of time pressure.

Thanks for all the input,

-Arne

>Arne,
>
>I haven't read all the thread but here are some observations:
>
>1) You say below that it must be something to do with the EXE (c.f. the prg)
>- Are you 100% sure that the exact same data and conditions are prevalent in both???
>
>2) People have asked if you're sure that the selected table is not at EOF() during exe error.
>- they aren't asking for nothing. Have you answered the question?
>
>3) Someone outright told you to use the IN clause of REPLACE. I see from this message that you haven't ried that yet. I recommend that you do AND that you learn to use it everywhere.
>
>My main point is that you seem to be letting your conviction of a difference in execution between exe and prg overrule anything people suggst. That's not a good strategy.
>
>Jim
>
>>I haven't tried this yet but:
>>
>>a) wouldn't it throw an error if we try to replace a non-existant field?
>>and
>>b) why would it work running the PRG/form but not the EXE?
>>
>>the solution has to be releated to the EXE version specifically. Does anyone know of a bug related to named references or macro substitution under VFP6?
>>
>>-Arne
>>
>>>Please leave it without any macro substitution at all :)
>>>
>>>Maybe the wrong table is selected? Add the IN clause to the replace.
>>>
>>>

>>>REPLACE (TVar) WITH "AO" + cOrder + cLine in tableName
>>>

>>>
>>>Perhaps (for testing purposes) you should add a BROWSE right before that command, so you can see the table (and record) that is currently selected.
>>>
>>>
>>>>
>>>>thanks for the response; unfortunately, I have tried that as well with the same result. I have also tried to execute the entire command via macro substitution like:
>>>>