Hi there, In the "Find" page, I changed the default of the "Show last" drop down box in the Entry Date section from the (unstated) "All time" to "Day", and added back in an "All Time" option at the very bottom.  This gives a default of searching the last day, and one has to think and select the period of time to search back on.

I did this on my 2.9.2-2475 version, recompiled and it works.  Two lines of code changed and even my cr*ppy coding was up to the task.  I don't know if Stefan would want to put this into the Master copy (I'll forward the changes if you want Stefan, but it's pretty easy if I can do it), but if you can edit and recompile (Eoin) I can tell you which to lines for immediate functionality.  Back up everything first, though!

It has just occurred to me that you may also have to check the non-English files, (./resorces/eloglang_xxxx) as this change introduces a new term "All time" that would need translation into the other lexicons.

By the way, in further testing, the "Show last" selection over-rides whatever two dates are selected, so if you ask for any entry in Dec 2014, but the "Show last" selects "week", nothing is found - very quickly.  I trust that is what you're after, Eoin.  I'll keep my change to the coding, but that's personal choice.

David.

If my coding had been up to it, I would have done this and submitted...  thanks Stefan.

Hi Banata,

If you only have a few people who can reply, then use

Allow reply = <user list>

and no need to produce a "Deny reply" list.

If most people are able to reply, but a few are *not* allowed to reply - bad behaviour or whatever - then the Deny reply list is more appropriate, and no need to generate an "Allow reply" userlist.

David.

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...