Hi,

I'm getting the TEXTSIZE TOO BIG message every time I have more text in my entry.  I understand there is a way to increase the TEXTSIZE and re-compile.  Where can I find the TEXTSIZE parameter that I can increase and also how do I re-compile.

Appreciate your help.

Thanks.
Illam

We have been successfully using the TCK-##### for several months and suddenly today it has stopped incrementing. We were at ticket # 40 and this morning any new tickets come up as 12 and never increment? We have tried restarting the elog service. Any suggestions would be appreciated.

Thank You

Don

Since I'n not a programmer I's like to be very carefulls with bug  
reports, but after testing for a while, I belive this my be a bug or  
something else:  
  
I have 2 systems running ELOG 2.5.1:   
1. uSE Linux 8.2, KDE 3.2 = NO problems at all! ELOG work's in every  
function quiet well!  
2. The Internet Server (of my friend): Windows 2003 Server, All MS paches  
installed, Running IIS 6.0 Port 80) and ELOG 2.5.1 (Port 8080) under  
FireDeamon 1.6GA (actual release) as a Service (Deamon).   
  
Problem under Win 2k3:  
This works very well, even with several users on the system and on ELOG  
as long as there is not msg. threaded! Is a Msg. Treaded ELOG produces  
the msg. showen in the attached Jepg-file below on Win 2k3.  
The problem occurs as soon as Elog would change to the threaded display 
or by clicking "Repaly" in the menu. Rights etc. are aleady checked on 
the file system and are looking well. Everithing will work well as 
nothing is thraded or testing locally under Linunx. 
 
Does anybody  
have an idea??? It my by a bog on Elog as well as from Microsoft or a  
problem produced by a dummy user (me...!). Since Linux don't have the  
problem and the same cfg-file and log-files are working well if I don't  
use mode=threaded as well as Display mode = threaded I believe it my be a  
realchance not to be the personal factor of the dummy user...   
  
ThankX for every hint!  
  
  

Good Morning,

I would like to limit the ability to edit certain attributes in an ELOG logbook, depending on the user who is logged in.  I.e. if "guest" or a standard "login user" is logged in, I only want to allow the user to edit "attribute1" & "attribute2" of say, 5 attributes.  However, if an Admin user or specific user, say "Terry" or "Bob" is logged in, I want to allow ALL 5 attributes to be editable.  To expand on this, I may want to even limit the visibility of the attributes as well.

I've read though "Condition Attributes" section of the help page, but it is not clear to me how/if I can do this?  Is that section even relevant to what I want to accomplish?

Can anyone provide some guidance?

Thank you for your time & help!

Sincerely,

Terry

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.