Is there a particular reason you are creating and closing the file in a separate process? It would seem to me that, especially given that the polling process keeps grabbing the file before you've put data in it, it would make more sense to create the file, write to the file and then close the file.

Either that, or see if you can talk the owners of the polling process to look for a flag file that is created after the data file is created.




>>>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
>>
>>
>>The first thing to check is the value of lnhandle
>
>... I think I have sorted it. My app interfaces with an application supplied by our courier - this polls a folder periodically for new files and grabs them for processing. It looks like what is happening is that the courier application is grabbing my file after I have created and closed it but before the write routine has run. When the latter does run it can not access the file to write the text - it will only be milliseconds later, but if the other app has grabbed the file handle that will make the file unaccessible!
>
>When I tried to simulate the 2 pieces of code by combining them into the single block above , by stepping through in the debugger I found that the text did not write to the file - but when I subsequently ran it outside the debugger it worked fine. I was making the erroneous assumption that there was something wrong with the code when in fact it was simply not working correctly in the debugger.
>
>So, as I say, all sorted I think......
>
>Barry