Greetings Tomaz,
As long as Kepware is reading from the CSV file, then the OS will hold that file in a 'locked' state preventing any other application from opening or editing it. This is a limitation of the OS file sharing, not a limitation of Kepware.
The only way to make the CSV file available for edit by another application is to force the Kepware runtime to release it's ownership of the CSV from the OS. Without restarting the runtime, this would have to be done by the OPC client you are using to read those values as tags releasing all active item references from that specific channel and device. In short, the client has to stop asking Kepware to go read those tags.
Once those active item references are removed, then the CSV file access will no longer be required by the Kepware runtime and we will release the file allocation request to the OS. Windows will then 'free up' the file for another application to gain access and make the edit.
When the OPC client needs to read those tags again, it will have to re-add the items to the Kepware interface and then our runtime will ask the OS to access the file again. As long as the other application that is making the edits has released it's allocation, then Windows will let Kepware access the file to then perform the read of the updated CSV content.
Example:
Client connects to Kepware, does not subscribe to the tag items in the channel/device pointing to the CSV, but instead does an OPC Async Read Request, then disconnects from the runtime . Kepware will then request access to the CSV from the OS, read the contents and then relinquish the file access request after the client disconnects.
The next time the client needs to read updated content from the CSV, the cycle repeats.
While is is ineffective client design, it can be used in this scenario for only the tag items required from the CSV data source.
Best regards,
Andy Servetas
Principal Technical Support Engineer | Kepware Technologies