Multiple user access to files with Formatting and I/O Library

[kirkm]

I'm developing a data-logging application using LabWindows/CVI 2013.

This is for a life test that will run for 2 years uninterrupted.
It will save data at a rate of about 20 bytes once per second.
I figured the app would open, write, close every sample.

I would like to keep the data logging application simple and build some sophistication into a separate application for analysis and progress tracking.

I'm thinking about using the file access functions in the Formatting and I/O Library.
OpenFile, CloseFile, ReadFile, WriteFile etc.

My question is:
Using this library, will the analysis application be able to be used by multiple users to open the log data file for reading and analysis while the logging continues?
I plan to put the log file on a network drive that is accessable throughout the company.

No writing to the log file will be allowed.

Also would like the logging app to periodically copy the log file to a backup.  Again this is while logging continues.

Thanks,
Kirk

[Wolfgang]

Hi,

just few thoughts:

- I would not put the log file on a network drive, the network might be down (especially considering the time frame of two years...)

- one way to avoid access problems might be to have a copy of your log file on the network drive; this one can be read even if the original log file is written; alternatively, create a new log file every xx minutes

[RobertoBozzolo]

I second Wolfgang opinion, particularly for what refers to the network side: you cannot guarantee that the network is permanently on for such a long time with a one-second access!

Your program can periodically append to the networked log file (after having checked the network is on) and other clients may look at the backup log without problems due to concurrence on the same resource.

[kirkm]

Roberto, Wolfgang

I hear you on the possiblilty of the network being down at times.  Good point!

The idea of periodically making a copy of the file is interesting.

In any case making a periodic backup of the data will be a must.

I was also thinking of maybe just logging twice.  Once to a network drive and once to the local drive. Two identical files in progress at the same time.

The network file would be "live" and up to date and could be access from anywhere on the network.

I'm planning on having the logging software write some summary status info to a header at the beginning of log file with each sample ie. total samples so far and some averages of the data.  Would be used by the remote viewer to display progress of the test when the app is running.

Can I get away with having  the "viewer" application do read only access to the log file while it is in progress?  (like when the header is being written to)

Or do I have to do something special to avoid reading while the logger is updating the header?

If so I could use some ideas on how to go about doing that.

Much appreciated,

Kirk

[RobertoBozzolo]

I am sorry but what I was thinking of was the exact opposite of your last post. I suppose Walfgang is on the same path.

If you want your application to run for such a lng time and keep a one second update to the log file you should not have any access to network resources, or you should limit it at a reasonable minimum.

Now, rethinking to your scenario, it's my opinion that your app should not take care of distributing its data: the critical point of the system is your app and it should take all data locally, you cannot run the risk of a one-minute timeout on a network access every now and then.

Since the others are simply monitoring the process and are supposed to be interactive applications on human control, lent them take care of possible network malfunctions.

The double layer is a good point instead: it is on the path of separating and isolating critical points (your app) for the rest of the world. Keep a "private" set of data used by your app only, and a second, non-critical, shared set of data available to the others; let them access this resource only from remote stations; do not permit access to private data file.

[kirkm]

Thanks for taking the time to think about this application. 

A question regarding last sentence:

"Keep a "private" set of data used by your app only, and a second, non-critical, shared set of data available to the others; let them access this resource only from remote stations; do not

permit access to private data file."

Will there be any problems if the remote stations access the non-critical shared data while the critical logging application is writing to the shared data?

Kirk

[RobertoBozzolo]

Sorry for late response.

I tend to say that until your program accesses only local resources it should be safe, events on the network side should have no effect on it, provided the "client" accessing the data do not generate locks on the file.

[kirkm]

No worries,  I appreciate your help on this.

I'll let you know how it is working out when I get further along with the code,

Kirk