Using Read & Write Text file vis with same refnum/path

[EJW2003]

I am trying to read a text file with the read text file vi, process it and write back to it with the write text vi.  However, I keep getting errors writinig back to the file (5 or 8).  I have attached a simple version of the three methods i tried.  Using the ring control to select the method, the error is output to screen.  there is an attached sample file to use with it. the file path constant is set to c:\  so you may have to change that to use it.

[LV_Pro]

I'm not seeing a problem running it except with the "path and refnum" example, which is a result of using the refnum output of the read, as the read function reads the file and then closes it, which makes that refnum invalid.

[chrisger]

hi there

i can confirm with LV 8.20 XPSP2 that the "path and refnum"  case causes error No. 8. for me this seems to be a bug in LV

[EJW2003]

Brain freeze on the refnum, however the other 2 methods don't work on my labview (8.2.1)

[EJW2003]

Double Brain Freeze.  I knew I was tired today but... I had generated a quick table using Excel, then saved as a tab delimitied text file.  I did NOT CLOSE the Excel File. 

Labview was able to Read the file just fine, but was unable to Write to it as the File was still open in Excel.

Time for a nap. 

[chrisger]

hi there

the refnum output of the read function in the "path and refnum" case is NOT null, and a subsequent read after the first read using the refnum returns no error, so the file is still open, but it seems to be write protected after a read. so for me this is a bug.

[GerdW]

Hi EJW2003,

for the refnum case:
The first operation (read from text file) opens the file in READ ONLY mode, the second operation (write to text) wants to write to a file opened in READ ONLY mode giving you error 8 (file permission error). Simple explanation...

Solution:
Before the "read from text" you have to put a "open/create/replace file" with access mode "READ/WRITE" (standard setting) and wire the refnum to both file operations...

[chrisger]

for me it does not make sense to lock the file as read only after i read it. the only thing i can do is to read the locked file over and over again, without the chance that anybody changes the files content.

[GerdW]

Hi Chris,

for me this makes sense.
In a multitasking environment several programs can access the same file. When I want to read a file I open it in READ ONLY mode giving other programs the chance to read the same file too. When I open it in READ/WRITE mode other programs are getting problems because now their file read operations depend on the status of my program - they don't neccessarily get the actual state of the file (concurrent read and write accesses to the same file). The operating system has two options to attack the problem: deny file access or (like Windows Office does) open a copy of the file in read only mode. All this I learned years before Windows came up

Conclusion: When you open the file with the "read from text" operation it should open the file in READ ONLY mode to coexist with other READ ONLY operations. When you need both READ and WRITE access you have to open the file with those settings!

[chrisger]

Hi Gerd

ok, i had an other philosophy in my mind: when i use the read file function and the refnum generated by it i do this because i want to use the refnum after the read function for some other purposes (e.g. for writing some other data to the file). when i don't want other apps to write to my file at the same time i open it explicitly with DENY WRITE mode. it hink the default READ ONLY mode should have been mentioned in the help (because the default mode of the file open function is READ/WRITE)

In READ ONLY mode other applications can still write to the file while it is opened by the read file function, so i can use this constellation (path in, refnum out) only for subsequent read file operations (e.g. to observe what other apps write to the file). because the Set permission function only works with paths i have to reopen the file when i want to write to it, so all in all i agree with your post.