>>>>>The problem is the use of ALLTRIM with a field longer then 10 chars in SELECT SQL. Look at message#01684075, I gave all the info were the problem comes from there.
>>>
>>>Thanks, Lutz! And your explanation holds up with various other tests- e.g.
>>>
>>>

SELE ALLTRIM(LEFT(c1,4)) AS c1 FROM mycur INTO CURSOR cmycur

>>>
>>>It processes the LEFT to decide field length, but not the ALLTRIM. It's as if the VFP parser is "smart" enough to know that ALLTRIM() can and I'm sure used to deliver undersized resultset fields. So, ignoring alltrim() when calculating selected field lengths makes sense, but a cause for unexpected issues as seen by Dmitry!
>>>
>>>FWIW, I'm pretty sure there was a time when you had to PADR() expressions to prevent undersized results, with confirmations as recently as 2003 on internet search- but I can't provoke it now by using SET ENGINEBEHAVIOR 70 etc. Maybe it got fixed in VFP7, leaving dinosaurs like me laboring on with obsolete truths. ;-)
>>>
>>>I experimented using varchar; your example now works as expected, yielding a V(10) result field with len(c1)=0 for first row... , but the same issue Dmitry saw with replicate and V(15).
>>
>>Yes, I have learned a lesson.
>
>Me too. In special about odd error messages . :)

Just FYI, I ran these examples that we discussed in the SSMS (against SQL Server). And SQL Server does not give you an error. What it does, if REPLACE() comes across a negative number, the SQL set the calculated column to NULL.
I don't know though which is better, VFP or SQL.