Certainly, I wrote the "part" part with a grin myself, but the left to right behaviour comes from the xBase engine from what Aleksey wrote, and it must one entangled mess the way he tactfully described it ;-)
>According to Mike's earlier testing UPDATE - SQL supports up to 255 columns, so it's safe to say that command doesn't re-use that part of REPLACE ;)
>
>>I have no idea of the code behind it, but the update - sql reuses the xbase replace code at least in part. Have this from Aleksey, as we were discussing the left to right working in update sql, which is not the way the big engines do it. No way to to add another enginebehaviour to fix that discrepancy, even when they were aiming at better SQL compatibility back in vfp9...
>>
>>
>>>>>>>>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
>>>
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.
