That's how it is implemented. If you use

Max email attachment size = 1000000

then attachments below 1 MB are sent as attachments, and if the attachment is above 1 MB, then only a link to the attachment in the elog is sent.

Stefan

We are installing a new data center which will be based on Windows 2012 servers.  Our current center is on Windows 2008 and will be decommissioned this year - 2008 servers (because of the security issue) will not be allowed in the new data center.  So game plan is to install latest ELOG (3.1.2) on the 2012 server at the new data center and move the logs over from the 2008 server.  I've looked through entries and do not see anything about moving the logs over from one system to another.  In this case there are 2 concerns:

1.  Has anyone moved the log entries from one system over to another?

2.  Since we are also looking at updating version of ELOG - are there conversion steps necessary for the log entries or will v3.1.2 be able to use the log files from v2.9.2 as is?

Thank you, Lesley

Just stop the server. Move your elog directory to the new server (including elogd.cfg, logbook directories, ...). Then check that the elogd.cfg needs modifications, like the URL which might have changed, then start the new server. V2.9.2 did have an old data format, which *should* be converted automatically. But first try it out before deleting the old server.

Hi Lesley,

Perhaps I can restate Stefan's comment.  The data structure of an elog entry, or indeed the structure of daily file(s) for any particular logbook has not changed between v2 and v3.  What has changed is the directory structure.  A set of sub-directories (named by calendar years) are added to each logbook, and all entries/files for any said calendar year moved into the directory for that year.  It gave me a shock the first time I tried using v3 elog, I wondered what it was doing  - it was the auto-conversion to v3 file structure.  I had to convert it all back to v2 file structure, so as to continue to use v2.9.2, so I'm pretty sure there is no change to the data structure within any file, else I think the older elog would kick up a fuss.  As an elog (ab)user, I've plenty of practice with the struture of the data files.

(There was a data structure change between v1 and v2 elog).

Thank you Stefan - it will take a couple of months to set up (many servers being built at the new farm).  I will update you on the success of the files converting automatically.

I've inherited a position that includes deploying elog for an at-sea mission. Once at sea there's no gauntee of internet connection so I have to be sure things are going to work before hand. The machines I currently have (we have several backup machines) are running elog version 2.9.2 and I'm looking for a change log, or feature list to determine if it's safe to update the at-sea laptops to the latest version of elog.

On one hand, I could leave things as they are and I'm sure it will just work, on the other hand, I hate seeing things get out of date to the point that something just stops working some day and there's no ability to get support for old software.

I'm already running elog 3.1.4 on my personal machine I use for configuration development and testing and it seems to work well. The config file is pretty simple and seems to work with 2.9.2 on the at-sea machines, but I don't want to run into any suprises if there ends up being a compatibility issue at sea.

If 3.1.4 runs safely on your laptop, there should be no problem to update the 2.9.2 one. But first do it on a copy of your logbooks from the at-sea. The get converted automatically into a newer format but that should be transparent.

On the other hand you don't really need a new system if your old installation works fine and you don't need any of hte new features.

The changelog ist here: https://elog.psi.ch/elog/download/ChangeLog

Stefan

Thanks. I did eveuntaully find the change log and made the decision to upgrade the at-sea machines. So far the configuration file we update for each mission still works. I have a copy of the 2.9.2 installer that if something catostrophic happens I can remove the new version and take it back, but I don't think it'll be a problem. We archive logbooks at the end of a mission, but each mission basically starts from a fresh install like state anyway.