>>>>>>>I have seen building SQL with embedded semicolons cause a syntax error, and removing them either programmatically before the macro or not adding them manually in the first place not have the error. Why is the length different depending on the alias and/or field names too?
>>>>>>
>>>>>>Sorry Mike, I give up, cannot find what might be the problem and I spent to much time already on this (by the way, all my tests I did them using execscript instead of macro and got the same results, so is not macro specific)
>>>>>
>>>>>Thanks for trying Hugo. It looks like there is a maximum of 128 fields that can be updated in a single REPLACE command. I never saw that in the help. So such code would have to concatenate until the length of line is under 8192 and there are less than 128 fields in the command. Wow,
>>>>
>>>>So it would seem. Following code is OK at 128, fails at 129:
>>>>

>>>>STORE "" TO lcCmd1, lcCmd2
>>>>
>>>>FOR lnIx = 1 TO 128 STEP 1
>>>>	lcFld = "F" + PADL( LTRIM( STR( lnIx ) ), 3, "0" )
>>>>	
>>>>	lcCmd1 = lcCmd1 ;
>>>>		+ IIF( EMPTY( lcCmd1 ), "", "," ) ;
>>>>		+ lcFld + " I"
>>>>	
>>>>	lcCmd2 = lcCmd2 ;
>>>>		+ IIF( EMPTY( lcCmd2 ), "", "," ) ;
>>>>		+ lcFld + " WITH 1"
>>>>
>>>>ENDFOR
>>>>
>>>>CREATE CURSOR Test ( &lcCmd1 )
>>>>
>>>>REPLACE &lcCmd2 IN Test
>>>>

>>>
>>>It's really unfortunate they did that. Why would they NOT match the number of fields in the table?
>>>
>>>Does anyone talk to Francis Faure regularly? This should be added to the foxhelp on VFPX.
>>
>>Even as far back as FPW2.5 the field limit per table was 255. Running the above code at 128 yields the error "Compiled code for this line too long". In that version the max number of characters per command line was only 2K.
>>
>>There was no UPDATE - SQL command in that version so there was no workaround using that. Dunno about the UPDATE (non-SQL) command, I can't recall ever using it. Also dunno if SCATTER... GATHER could be a workaround.
>>
>>Here's some pure speculation - code like this is legal:
>>

>>CREATE CURSOR Test ( iTest I )
>>APPEND BLANK
>>
>>REPLACE iTest WITH iTest + 1, iTest WITH iTest + 1
>>
>>?iTest && 2
>>

More generally it could be a function call e.g. REPLACE iTest WITH SomeFunc( iTest ), ...
>>
>>Superficially it looks like the clauses are processed sequentially left to right, but internally it might not be. Maybe it uses some sort of internal stack, or nests subject to the DO nesting limit. With that in mind I tested by starting VFP9 with STACKSIZE=256 in CONFIG.FPW but the error still occurs.
>>
>>Yes, it is a mystery. The problem was there back in 16-bit FPW, when the product was still in active development, and there wasn't an obvious workaround like UPDATE - SQL. Why was it not fixed then? Maybe no-one noticed it.
>>
>>Or maybe it was only noticed later, when UPDATE - SQL was available and dev budgets were tight so it wasn't considered worth fixing.
>
>Which brings up a pet peeve of mine - is it actually reasonable for the update command and the replace command to be totally separate functions internally? They do exactly the same thing. In any case, it's out in the open now.

REPLACE has been in xBASE since dBASE itself, and the earliest versions of FoxBASE. The SQL commands were added later as part of what I gather is a separate "SQL engine" in the code base. ISTR John Koziol making general comments about the quality of the "legacy" C code from the early products that remains even in VFP9, and that the dev team didn't want to touch any of that with a barge pole. That said, you probably noticed in another message that Aleksey Tsingauz apparently told Thomas Ganss that UPDATE - SQL does re-use some of REPLACE's code, FWIW.

With no possible update to the MS VFP product I don't see much point in getting bent out of shape about apparent inconsistencies in the language. It's vastly more important to characterize the product as it is now, and this discovery of a limitation of REPLACE is a useful finding.