>Hi
>Could someone point out what is probably blindingly obvious - I can not get the following code to write to local text file?
>jn returns 0 each time through the loop.
>
>(I am creating and closing the file before opening it again because in my application the file creation is done in a separte method to the writing of text to the file.)
>
>

>
>USE USERS IN 0
>lcfname = "C:\temp\testfile.txt"
>lnhandle = FCREATE(lcfname)
>FCLOSE(lnHandle)
>lnHandle=FOPEN(lcFname,12)
>SELECT USERS
>SCAN 
>   jctext = USER+","+NAME
>  * Write the record
>  jn=fputs(lnhandle,jctext)
>ENDSCAN
>
>=fclose(lnhandle)
>
>

>
>
>Thanks
>Barry Sutton

As has been explained by others, what's likely happening is that the other program is grabbing the file between the time you initially close the file and re-open it. You're able to simulate this while in debugger as it widens the "window" between the FCLOSE() and the subsequent FOPEN() -- it is very unlikely you'll be able to simulate this in a "live" session due to the narrow time window.

If you're not able to change your code where you're creating the file (basically leaving the file open, then passing back the handle so that it can be used later in the part that updates the contents), you can basically do the following:
(method that creates the file)
1. Create the file using a different filename than the "target" filename and/or "target" folder (but using the same physical disc)
2. Close the file
(method that updates the file)
3. Re-open the file (using filename used in step 1)
4. Update its contents
5. Close the file
6. Rename/move the file to "target" filename in the "target" directory.

NOTES:
* You've no worry about the other program "seeing" the file before you've finished updating it (since the file won't have the appropriate filename)
* Reason for why I mention folders that reside on same physical drive -- rename/move operation at that point only involves a unlink of file entry and then re-link into a different folder. Otherwise rename/move would involve COPY followed by DELETE.