I'm also happy to see this change implemented as we've had to deal with the same issue at times as well. Will this change be incorporated into the latest version (314-2, aka elog-latest.exe), or will there be a new version release (that is not in Changelog yet)? If so, can you give any ETA on this new code availability?

Also I noticed that the Elog Home page still says "Current version is: 3.1.2". I assume that only means it hasn't been updated, not that it means it's the current STABLE version and subsequent releases are beta -- please correct me if I'm wrong. I just want to make sure I understand how the versions and releases work.

Endless thanks for this product and all your work Stefan.

Is it possible to include an option in the next release to have the Options list reference a text file of attributes rather than explicity listing the attributes in the Config file directly?

This would make it much easier to maintain a particular list that is referenced in several log books.

"I committed" means that the change is sent to the GIT repository. People who compile from the source code can pull and compile immediately. Windows users have to wait until I do the next release. I'm developing on a Mac and have to boot a special (old) Windows machine to compile the .exe which each time takes me about one hour including documenation updates, changelog updates, upload of zip files etc. Since my main job is heading a research group, I only can devote this hour once in a while, depending on my work load. Sometime even the weekends are too short.

I can put it on the wish list.

Just my two cent - I would have many very good applications for that feature:

• Keep option lists identical over different logbooks.
• Keep option lists identical over different applications.
• Create option lists from a database - that allows to use the options in many applications and in the database; e.g. a list of systems with a failure database, but failure reports in the regular ELOG.
• Export extendable option lists to other applications:
  • Inform administrator about options that have been newly added to a logbook for a review.
  • Provide option lists as menu buttons in these applications.
  • Prevent other applications to submit elog entries with illegal option choices.
• Import extendable option lists from other applications (at least after next elogd restart, if no "update option list" URL/command is provided for elogd).

We recently went through the process of renaming a "system list" in several logbooks, to make it consistent over several facilities. If the "on-call service" is called "radio frequency", but the "system" is called "RF", then searching the logbook can become difficult. It was painful: half a dozen applications had to be adapted at the same time the lists were updated, because they had features to create a failure report to ELOG - assuming specific "system" names.

So I'm in favour of putting that high up in the wishlist :-)

We have a number of temperature chambers – each has its own laptop running a local ELOG server, with unique logbook for each.  Using the mirror feature, these individual logbooks periodically synchronize to a single remote desktop server, which has a copy of each of the logbooks.  All of that works great, as long as each of the ELOG servers are storing the logbook(s) to their respective local hard drive.

I wanted the remote server to store its copy of the logbooks on the network file server.  I changed the global options of the elogd.cfg file, adding the following:

               Logbook dir = S:\SHARED\LOGBOOKS

That change worked fine on the remote desktop server – new logbook entries were now being stored on the network file server.

Unfortunately, I lost the ability to sync from the individual logbooks to the remote desktop server.  During synchronization, I now get the following error message: “Error sending local entry: Error transmitting message". 

Has anyone run into this? Does this make sense? Am I missing something? Is there a workaround? Is there a wrong time to drink beer?

Thanks,

Frank