>Hi everybody,
>
>In BatchCntrl table I have an index in Bintoc(DsID)+ExtrYear+ExtrWeek.
>
>I'm passing DsID as a parameter in a form method. Here is a piece of code:
>

>lcIssue = .ThisIssue
>	select BatchCntrl
>    lcOldOrder = order()
>    set order to DsIDWeek
>*    BINTOC(dsid)+extryear+extrweek
>    lcFor = iif(vartype(m.tnDsID)="N",;
>            [for bintoc(DsID)+extryear+extrweek=bintoc(tnDsID)+lcIssue], ;
>            [for State+ExtrYear+ExtrWeek=']+ m.lcStateWeek+['])
>	scan &lcFor

>This doesn't seem to work. Originally I have
>

[for bintoc(DsID)+extryear+extrweek=']+bintoc(tnDsID)+lcIssue+[']

, ;
>which gave me error on SCAN line. lcFor contains some symbols, which probably & can not recognize.
>
>What can I do here? Change it to separatly use DSID and ExtrYear, ExtrWeek (e.g. don't use DsIDWeek index). I probably can add two more indexes in my table to still use Rushmore optimization.

The reason the initial For clause didn't work is the macro substitution where you tried to put a result of a BinToC() into a literal. BinToC() generally creates an unpredictable binary content, and while VFP may tolerate any content in the strings, I'm not sure of the content in the string constants (which is what you got after macro expanded).

I was using BinToC() in indexes for a while, and sometimes they are the only solution that's quick enough. The function itself is probably just a few lines in C++, so it should not introduce more overhead than using, say, upper().

The way around your problem is not to use the string literals in the macros, but use a variable:

lcRightSide=bintoc(tnDsID)+lcIssue
lcFor=[for bintoc(DsID)+extryear+extrweek=lcRightSide]

I'm not sure whether the right side of the condition would or would not be recalculated for each record, but this way it surely would not be.