>>>>The index always accepted variable length strings. In cases where the function, like sys(2007) returns variable length, you have to pad it out, as I understand it.
>>>
>>>When the index is created, it takes the length of the value as the length of the index. So depending on what's in the first record at that moment you get different lengths and then for other records the tag value is stored in that length. Perhaps you accidentally had one in the command window which evades the error, and another one when running the code?
>>
>>Perhaps Lutz did, yet.
>
>The code is
>

>*next line fails
>					&lcIndex.
>				ENDFOR
>
>
>				USE IN (SELECT(JUSTSTEM(.c_OutputFile)))
>
>				*-- La actualización de la fecha sirve para evitar diferencias al regenerar el DBF
>				IF toFoxBin2Prg.l_ClearDBFLastUpdate THEN
>					ldLastUpdate	= EVALUATE( '{^2013/11/04}' )
>				ELSE
>					ldLastUpdate	= EVALUATE( '{^' + toTable._LastUpdate + '}' )
>				ENDIF
>
>				loDBFUtils.write_DBC_BackLink( .c_OutputFile, toTable._Database, ldLastUpdate )
>
>				toFoxBin2Prg.updateProcessedFile()
>			ENDWITH && THIS
>
>
>		CATCH TO loEx
>			lnCodError		= loEx.ERRORNO
>			toFoxBin2Prg.updateProcessedFile( 0, '', '', 'E1' )
>			loEx.USERVALUE	= 'lcIndex="' + TRANSFORM(lcIndex) + '"'
>
>			IF THIS.n_Debug > 0 AND _VFP.STARTMODE = 0
>				SET STEP ON
>*this line stops
>

>now in command window &lcIndex. runs.
>
>Since we are in a TRY, we can not simply set the Next Statement
>
Ok, the problem was where record pointer was located in the moment INDEX ON was issued. The operation before moved it to a place where it was only 9 chars long. So it looks like the command starts with the record where it is, and then starts from top.
The command fails depending on the record where the command is issued.
After the error the record pointer simply was 1 - and that results in len 10.

Nice - something learned