>>>>>Hi,
>>>>>
>>>>>The following code works when I run it from the VFP 9 IDE. But when I compile the program and run it from the .EXE I get error "Cannot update the cursor 3733373 since it is read-only"
>>>>>
>>>>>What am I missing?
>>>>>
>>>>>

>>>>>lTempAlias = sys(2015)
>>>>>STRTOFILE(FILETOSTR("ReportName.FRX"), FORCEPATH("ReportName.FRX", getEnv("temp")))
>>>>>STRTOFILE(FILETOSTR("ReportName.FRT"), FORCEPATH("ReportName.FRT", getEnv("temp")))
>>>>>USE (FORCEPATH("ReportName.FRX", getEnv("temp"))) ALIAS (lcTempAlias) IN 0
>>>>>REPLACE Expr WITH m.lcExpression IN (lcTempAlias)
>>>>>

>>>>>
>>>>>
>>>>>TIA
>>>>
>>>>* I assume the first line is a typo "lTempAlias" should be "lcTempAlias"
>>>>* Make sure that the table name being returned by GETENV() doesn't match a table included in the project (i.e. the path doesn't matter in this case).
>>>
>>>the lTempAlias is just a typo in my message.
>>>
>>>But I don't understand your input regarding GETENV(). In my case GETENV("temp") returns the name of the TEMP folder. How would this affect the USE and REPLACE?
>>
>>My mistake -- GETENV() isn't the issue.
>>
>>What is probably the issue is that after you copy RepotName.FRX and ReportName.FRT to an external location, then ask FoxPro to open that external file, it opens the internal file (even if you specified the full path to the external one). The workaround is to use function SYS(2015) to generate a filename for the external copy.
>>

>>lcTempAlias = sys(2015)
>>lcExtName = FORCEPATH( "RPT_" + TRANSFORM(_VFP.PROCESSID) + "_" + SUBSTR(SYS(2015),3,10), GETENV("temp"))
>>STRTOFILE(FILETOSTR("ReportName.FRX"), m.lcExtName+".FRX")
>>STRTOFILE(FILETOSTR("ReportName.FRT"), m.lcExtName+".FRT")
>>USE (m.lcExtName+".FRX") ALIAS (lcTempAlias) IN 0
>>REPLACE Expr WITH m.lcExpression IN (lcTempAlias)
>>

>
>Yes, this was my problem. Thank you!
>I was wondering, if for lcExtName I use another sys(2015) as
>

>lcTempAlias = sys(2015)
>lcExtName   = sys(2015)
>

>is there a change that both will have the same name (since they are called so close to each other)?
>
>Maybe because I have never use _VFP.PROCESSID, I am not 100% sure it will work in all cases.
>
>UPDATE. Never mind my question. I ran about 1000 tests today with your syntax of using _VFP.PROCESSID and it never failed. So I am leaving your code as is.
>Again, thank you very much for your help.

I usually add the _VFP.PROCESSID factor just in case that there are more than one instance of the program running at the same time. As I'd stated earlier, the SYS(2015) does assure uniqueness within the same process, but if there are two instances of a program running, and they happen to use the SYS(2015) function within a certain "window", there is a chance that both instances will get the same value.. And yes, I have run into such a situation before (where two different instances collided), and addition of the _VFP.PROCESSID factor helped assure uniqueness in the filename.