Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

 Thanks for reporting that problem. It has been fixed in SVN revision 2156.

 Excellent! Thank you.

I installed ELOG on a Linux server (CentOS 5.2) and a WinXP laptop.

- If I set both servers to non-SSL, I can synchronize with no problems.

- If I set both servers to use SSL, synchronization fails with "Error code: ssl_error_rx_record_too_long" 

- If I set one to ssl and the other non-ssl, synchronization fails with "Remote server is not an ELOG server"

Is anyone synchronizing or mirroring two ELOG servers with SSL? When either or both servers are set to use SSL, I can use either site. but I can't synchronize.

Thanks

Synchronization with SSL does not yet work. I have to find some time to implement it. Since you are already the second one mentioning this, it slipped higher on my to-do list  

Hi, All.  We have been successfully using ELOG in a limited deployment for a couple years now.  However, we are about to embark on a new project that could run for up to 10 years, and are wondering what sort of scalability we can expect from ELOG.

Are there any problems we can expect to run into as the number of entries grow?  I see in a previous thread that "elog runs fine for a few 10000 entries. At 100000 entries it starts getting slow."  Is this still the case, or have any improvements been made?  What sort of problems would we expect to run into?  Any examples of existing large deployments would be very useful.

Many thanks,

Devin 

The above made statement is not true any more. Mainly due to the large CERN experiments, some speed improvements have been made in late 2007. So elog runs fine at least up to 100000 entries. The startup time might be a bit slow, since it parses all entries there, but beyond the maybe 20s startup time, there is not a big difference when browsing entries. The only peoblem left is if you try to search some text through 100000 entries, this could be a bit slow. I have not tried anhything beyond 100000 entries, because this was not requested so far. If logooks become too big, the entreis could be split into several logbooks. Even if there are several logbooks with 100000 entries each, the access time should not be slower than if there would be one logbook with 100000 entries.

 Could you post an example of what you used?