We use LoggernetAdmin v4.1 (running as a service) and have network file shares as the main location for data files to be stored.
Mapped drives don't seem to be available when specifying the path for these files.
A bit of a search through the forum and I found that this is likely to be due to the fact that LN is running as a service.
OK, so we need to specify the path using the full path name - for example: "\\server\fileshare\sitename\file1.dat"
What we find happens is that when this is entered into the filename field, the leading \ gets truncated, leaving "\server\fileshare\sitename\file1.dat".
Now, sometimes this causes a folder structure with this name to be created in the root of the local hard disk (C:) and writes the files there, and sometimes it writes the files to the correct network location.
When the files (and folders) get created in the local drvie (C:), we fix it by editing the filename path in the Setup client to add the extra \ back in. Once Apply is clicked, or even when you click to another site and come back (without Apply being pressed), the first \ is truncated again. Sometimes it works and sometimes it doesn't.
I'm not sure what the key to this is.
This occurs using the Connect Client with a localhost connection or a network connection, although it never seemed to happen in LN v3.4.1. It seems to have changed when we upgraded from v3.4.1.
Simon
I have confirmed the behaviour that you mention above. It would appear that the set up screen and the loggernet server both honour your initial values. Indeed, in my own tests, I can see the UNC path being used when the data file is opened. The problem seems to appear when the set up screen reloads settings from the server. Somehow, in this process, the initial backslash is being lost from the UNC. I assume that, at that point, if you make further changes to the file name, it will get saved in its mangled form. The work-around for the time being is to remember to replace the initial backslash whenever you edit the file name setting.
Thanks Jon.
That explains things for us and matches the behaviour that we see.
Just to confirm, new versions of Loggernet will have a fix for this Setup client issue?
Thanks
Simon