Hi Stefan,

I'm starting to get a similar problem to Lance's ("SQL Database").  Searching is beginning to take time.

In searching, I either can search one logbook (still relatively quick), or all of them.

I have my logbooks in groups, and often I know which group I want to search, and it would make the searching
much quicker were the search confined to just that group.  I don't think I've missed anything in the
documentation on this matter.  

If not a change to the elog program, is there another way of (say) arranging the logbooks that will achieve this?

We have been running elog for a few years now and its solid. The only thing is we are getting to 140k entries over a few books and its starting to slow down whist searching. My questions is can we go to an SQL type database rather than a flat file? Is it worth it? Is anyone running this type of configuration?

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it?

Details

We have two elog servers set up with identical elogd.cfg and password files, except that one server has "Mirror server" pointing to the other host. There are three logbooks defined.  (Their names are DoubleChooz, BigBrotherTable, and FlushingTable.)  When the mirror synchronization happens, whether by "Mirror cron" or by an administrator hitting the "Synchronize all logbooks" link, it often happens that entries requiring synchronization are corrupted on both servers (not just the one to which the entry was copied). This is particularly likely to happen if entries have been made on both servers since the previous sync.

Looking at the logbook files themselves, we see that the corrupted entries will have attributes from the wrong logbooks. E.g., we'll see an empty "Barometer: " line in a DoubleChooz logbook file, where "Barometer" is an attribute that is only in the FlushingTable logbook, or we will see there are unexpected DoubleChooz logbook attributes in the FlushingTable files.

Strangely, the entries will not be identical on the two machines after syncing, and they stay non-identical on further syncs.

Most disturbingly, data is lost from entries that were perfectly valid before the sync, on both servers.

This was happening with elogd 2.7.8, and continued to happen after upgrading to 2.8.0. Both servers are running Linux. One is a 32-bit machine and another 64-bit, in case that might matter (but read on).

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise.

Attributes = subject, ... 
Options <name> = test{1}, ...  

Subst myvar = $shell(dir) 
{1} Preset subject = Test 
{1} Preset text = $myvar 

 I am getting the same message in the current version (V2.8.0-2312), if the "Preset text"  text body contains the equal sign '='. Then this message pops up and the HTML-editor dosn't show its menu bars, with the elog- or plain text editor this does not happen. It happens as well with firefox as with internet explorer.

best regards

Robert

how to convert Common Era (C.E.) into Buddhist Era  such as C.E. 2010 to B.E. 2553   (2553=2010+543) .thank you

Will elog defer user identification and authorization to the ssl engine of a *local* Apache proxy?  I'd like to try elog in a site that requires the service port positively authenticate and identify users via smartcard certificate ID.  Per SOP they have Apache+mod_ssl setting SSLUserName=SSL_CLIENT_S_DN_CN which sets both the SSL request object's "user" field and the REMOTE_USER environment var relative to the mod_ssl's session's process group leader.  Users auth with Apache's mod_ssl as a single-signon replacement for web apps which have traditional native, internal user accounts/passwords, but those passwords are subsumed by the Apache/smartcard/mod_ssl setup.  The web apps define internal accounts matching the users' cert IDs but do not allow any management of the [unused] passwords.  Can elog do this?

 Since we updated to 2.7.8 we've found a problem.

Previously, when we used 

Subst on reply subject = Re: $subject