> Hi Francois,
> as far as I know there is a limit on the number of conditions you can use (See elog:67303).
> I guess you did hit that limit.
> 
> I think I've mentioned recently that ELOG is not a relational database, didn't I?
> It is of course possible to drive screws with a hammer, but there do exist more suitable tools for that ;-)
> 
> Kind regards
> Andreas

Got it...
But again, I found it strange that it works from time to time.... is it an elog limit or a javascript issue....

the guide mentions :
Options <attribute> = <list>
Usually, an text field is used for an attribute, where the user can fill in text of up to 100 characters.
but no words on options size...

I would say if it was a size issue it would not work at all no ?... but now it works from time to time....
But you are right, maybe I should get a bigger hammer :)

Seriously, I really hope It could make it... Could you try it on your side ? could I enable some sort of debug mode other than running elogd from a shell ?

>  
> > Seriously, I really hope It could make it... Could you try it on your side ?
> 
> My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
> - attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
> regardless of which line you remove!);
> - attach the entry data, if the behaviour depends on the data;
> - use a specific, to the point subject line;
> - explain what you did, what happened and what you would have expected to happen;
> - ask kindly; and then
> - wait and hope for the best ;-)
> 
> (This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)
> 
> BTW: This tip was absolutely free of charge ;-)

Andreas,
Thanks for your comments. Thats why I posted in the first msg my configuration details... I just hope there can be a solution :)
I saw in the doc that an attribute cant be bigger than 100 char. but I couldn't figure the maximum size for options...  I'm wondering if the issue comes from the browser not refreshing correctly or if its elog..
Again, I tought that if that was from elog limitations, the attributes wouldn't load the options presets at all... but they do, (attribute volume) ... just not all the time :)

I understand that you are proactive on this forum and eventually I was thinking of contributing with detailed specific config examples but for now I just would like to get on track :) 
The last time I used Elog was 10 years ago :) it changed alot since :)

> I came accross the admin guide and I was reading / searching for a way to sync logbooks across sites...
> elogd mention "-m" and "-M" ... not elog but elogd... with that description :
> synchronize logbook(s) with remote server

If you would have followed the shown link to the "elogd.cfg syntax page", you would have found the chapter Mirroring:
https://midas.psi.ch/elog/config.html#mirroring

> Does it sync all logbooks ? 

Not necessarily, but that is the default.

> is there any examples somewhere or advice ?

See above: you'll find examples under #mirroring

> Thanks :)

You're welcome.

Thanks

what is the format of the Date field in the csv file ?

My Date is date and not datetime. 

> elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> in the release announcement and in the release and migration notes. K.O.

That feature is one of the main reasons why the version jumped from 2.x to 3.x. 
A free tip: changes in major revisions do indicate some kind of incompatibility.
But yes, the release documentation by bitbucket is not really that useful: 
it is difficult for me too, to find out what changed with new releases. 
I have to admit here, that I haven't read any GIT tutorial yet.
By the way: you are welcome to contribute to the release documentation!

On your actual problem: to go back to a former version of ELOG you can simply
- stop elogd 3.X, 
- move all entries from the sub-directories one level up, and 
- start the 2.X version of elogd.

I wouldn't really call this an "incompatibility", would you? 
At least you can easily go back without much trouble.

Cheers
Andreas

> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
> 
> That feature is one of the main reasons why the version jumped from 2.x to 3.x. 
> A free tip: changes in major revisions do indicate some kind of incompatibility.
> But yes, the release documentation by bitbucket is not really that useful: 
> it is difficult for me too, to find out what changed with new releases. 
> I have to admit here, that I haven't read any GIT tutorial yet.
> By the way: you are welcome to contribute to the release documentation!
> 
> On your actual problem: to go back to a former version of ELOG you can simply
> - stop elogd 3.X, 
> - move all entries from the sub-directories one level up, and 
> - start the 2.X version of elogd.
> 
> I wouldn't really call this an "incompatibility", would you? 
> At least you can easily go back without much trouble.
> 
> Cheers
> Andreas
Stefan told me that the change was because some users were having thousands of yymmdda.log files
in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some 
order.  Possibly to get around the lazy archivers, I suspect.

When I first tried v3.0, I wanted to go back due to some bug or feature, and had to do exactly what Andreas suggested above.

David.