Not really, you are the first one reporting this issue. Just some thoughts:

- Can you see the changes if you look at elogd.cfg with a text editor such as notepad?

- Some write protection of elogd.cfg

- Do you have more than one server running at the same time and changing the wrong one's config?

- Stefan 

hello,

At home, when I change the config *. cfg, the modifications are not taken in consideration

Have you got a idea ?

Thanks a lot !

Bob

> If I create an entry via the web-interface, the defined encoding of the browser is used.
> If I create an entry via "elog", it is always stored in UTF-8 encoding.
> For the text I can overcome that with HTML encoding, but for attribute values the encoding does not show properly.
> The only solution I found was to convert the whole logbook to UTF-8 encoding:
> 
>  define "charset=UTF-8" in elogd.cfg
>  iconv --from-code=ISO-8859-1 --to-code=UTF-8 elogd.cfg >tmp;mv tmp elogd.cfg
>  iconv --from-code=ISO-8859-1 --to-code=UTF-8 resources/eloglang.german >tmp;mv tmp resources/eloglang.german
> 
> Has anyone any idea why ISO8859-1 does not work for me?
> 
> Or can anyone advice me of an editor similar to NEdit that is capable to display UTF-8? :-)

I just tried it submitting to the Demo logbook:

https://midas.psi.ch/elogs/Linux+Demo/15

using some German Umlauts, and saw that it works fine. "elog" does not do any conversion, just submits the text as is. 
If your text is ISO-8859-1 encoded, it will be submitted as such, and your browser will correctly display it. Have you 
tried removing the "charset=UTF-8" from your elogd.cfg?

If I create an entry via the web-interface, the defined encoding of the browser is used.
If I create an entry via "elog", it is always stored in UTF-8 encoding.
For the text I can overcome that with HTML encoding, but for attribute values the encoding does not show properly.
The only solution I found was to convert the whole logbook to UTF-8 encoding:

 define "charset=UTF-8" in elogd.cfg
 iconv --from-code=ISO-8859-1 --to-code=UTF-8 elogd.cfg >tmp;mv tmp elogd.cfg
 iconv --from-code=ISO-8859-1 --to-code=UTF-8 resources/eloglang.german >tmp;mv tmp resources/eloglang.german

Has anyone any idea why ISO8859-1 does not work for me?

Or can anyone advice me of an editor similar to NEdit that is capable to display UTF-8? :-)

 I installed 2.81 (Elog-latest) but this Version did not work. I got Error 193: %1 is not a valid Win32 Application as I tried to start the service. So i will sent you the complete elogd.cfg via Mail.

Best regards

Michael 

I tried your configuration and it worked fine:

So can you try version 2.8.1 if that makes any difference. If not, can you send me your complete elogd.cfg, so that I can reproduce your problem.

- Stefan

Hello,

i have a logbook with the following parameters for the Attribute "Typ":

[TEST1]
Options Typ = SDB{2}, Qualifizierung B.12.S227{4}, Qualifizierung PRO/REP{3}, Dokument zur Qualifizierung{2}, Prüf- und Wartungsvorschrift{2}, SOP ohne Change Request{2}, SOP mit Change Request{1}, Validierung PRO/REP{3}, Dokument zur Verifizierung{2}, Überprüfung und Verlängerung{2}, Spec.Sheet{2}, CoA (sofern nicht LIMS){2}, Änderungen Tg4.B07{5}, OOS (Plan/Bericht){3}, Transfer PRO/REP{3}, Studie PRO/REP{3}, Studie ohne Plan{2}, Anderes{2}
Quick filter = Date, Typ

If i choose an Entry from the "Typ" Quick Filter it shows me that there are no entries in the logbook but I'm shure that there are entries. 

Can you please help? I cannot see what's wrong.

Best Regards

Michael

Hi,

I have two logbooks based on the same data directory through "Subdir" option and when I add new entry in one logbook, then that entry is not visible in other logbook.

I suppose it is a bug in el_submit function, where I think the new message should be added to message index of every logbook based on the same data directory as the one, where the message was physically created. 

There is a piece of code, which I think should do this automatically

/* if other logbook has same index, update pointers */

but it seems the other logbooks does not have the same index. 

I'm new to elog and the sources are also new to me, so my guess to the ground of the problem may be wrong.

Let me know is this bug possible to fix in near future.

Best regards,

Jacek