I grant that this may be a complete red herring, but your description below  - not available and having to reboot - 
might have another explanation.  At least in Linux.

I have found that if you have a broken thread, and you try to access that thread, the daemon goes into an endless
loop and
I could not kill off the daemon by normal means, but had to reboot the computer.  The daemon cannot cope with not
finding 
an entry where one is referenced by a subsequent (or previous, I assume) entry.

A broken thread can occur if you move a thread with a large number of subsequent entries - more than say 50 (I
don't know 
the precise number) from one log book to another.  The copy part of the move works, but the deleting of the entries
in the 
original log book is incomplete, leaving an orphan set of (later) entires.  Access those, and it's time for a
reboot.  Which makes 
finding them a potentially tedius and multiple rebooting exercise.  I know, because I've had to track a number in
my time.

Just a thought.

David.


> We have reduced entries for Search reasons by removing older text files and that seems to speed up things. 
> However, a recurring problem persists during peak period where the service connection is lost (site says "Not 
> found" on both client and directly on server), and it cannot be restarted or killed. Only a reboot of the 2010 
> x64 virtual server will make it available again. 
> 
> Any further info or details I can provide please advise. Thank you Stefan.

Hi Stefan,

There's one pre-set value you forgot to include in this, which is the genuinely required "Show last all time".  I archive many logbooks by years, and so for the year 2005 (say), searching by anything other than all time will always bring up zero results.  And it gets annoying that the default default is "Day", the number of times I've forgotten...

I got around this by allowing a "Show last default = 0", modifying the relevent line in the block of code you modified when this was introduced to make this select "i==0", and that did the trick. 

Law of unintended consequences came into play.  If you use 0, then on the results page it says "Restricted search to last 0 Days".  So that also needs tweeking, and that's really put my c coding (or lack of it) to the test.  But I've changed that phrase to "Unrestricted search" followed by blank for when the parameter "last" is 0.

Oh, and a typo, "seach" instead of "search".

No doubt other features will show up...

Hi Andreas,

Yes, the empty string does exactly that, in the drop down menu, but before my changes, I could not set it to be the default setting in the configuration file.  In an archived logbook, it's perfectly possible for "all time" to be the only sensible value.  I tried "Show last default =  " and various other variants, with no success in getting what I actually required.  Also, in the documentation, there was no mention of a way to set the default as "all time", just a list of number of days (week (7), month (31), year (364) etc), which also led me to believe that it was not possible with the existing code.

I've sent an email to Stefan giving my coding changes for information.

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

Thanks Stefan, that did the trick.

Had a bit of an effort with the git repository, though, kept getting 403 errors when tried the

git clone https://bitbucket.org/ritt/elog as per the "download" page.

error: The requested URL returned error: 403 while accessing https://bitbucket.org/ritt/elog/info/refs

Hi Francois and Andreas,

On Francois' first question, I wonder if Francois is using attrib1, attrib2... as the actual attribute names in the config file.  If this is the case, Francois, you can name attributes with suitable names in the configuration file and dictate which ones appear in the List and Threaded display modes. In the List Display, those names appear along the top row at the top of each column, which I think is what you want. 

This example of three lines in a config file (made up).

Attributes = Worker, System, Organisation, Customer, Status, Ticket

List display = ID, Date, Organisation, Customer, Worker, System, Status, Ticket

Thread display = $Ticket: $Worker. $Organisation / $Customer, ($message id).

In list display, those words ("Organisation", "Customer" etc) are those that appear at the top of each column.  In Thread Display, note how you can use punctuation.  Also (not shown here) you can colour the line in Thread Display depending on the attribute System (which is akin to your question on cell style colouring) a feature not much used in this forum, and the Icon at the beginning of the line depending on the attribute Status. 

This is in the documentation, but perhaps it's not clear to all that - apart from the system defined attributes - any word can be used as an attribute name, and that "attrib1" "attrib2" is just shorthand for "any words you wish to use as attribute names".

Otherwise, if you want a different word along the top if the column in the List Display (and also in the form for making a new entry) for the attribute that appears in that column, why not just use that different word as the name for the attribute?

On the third point, about Cell Style, it would be good for having attrubute 2 able to dictate the colour of the cell of attribute 1, and no need to show attribute 2 in the List Display.  But take your point that it can be done in a shell script.