> i have expand flag set to 0 but it doesn't seem to be working...

It workes here flawlessly. Can you double check the spelling etc. If 
everything is ok, can you send me your elogd.cfg for analysis?

- Stefan

> > i have expand flag set to 0 but it doesn't seem to be working...
> 
> It workes here flawlessly. Can you double check the spelling etc. If 
> everything is ok, can you send me your elogd.cfg for analysis?
> 
> - Stefan

I checked your elogd.cfg: The flag is called "Expand default" not "Expand" as 
you had it. With "Expand default = 0" it works fine. Just RTFM...

- Stefan 

> I checked your elogd.cfg: The flag is called "Expand default" not "Expand" as 
> you had it. With "Expand default = 0" it works fine. Just RTFM...

i could probably recite the manual from memory :/ i wouldn't ask if i wasn't confused about something.

i thought the 'default' word was explaining what the default was for the 'expand' flag, not an actual part of the flag. 

> Another thing that seems to slow the site down, is the number of users in 
> the elog notification list (those who've subscribed).  When you save a log 
> entry, it takes around 30sec or longer for it to actually complete the 
> save.  If I remove the list of users from the notification list and just 
> have a few, the save is very fast.

This problem will be fixed in version 2.2.5. Prior to 2.2.5, individual 
emails were sent to all recipients. Since each email takes 0.5-1 sec., this 
procedure can be very long. From 2.2.5 on, only one email is sent, but to 
all recipients. The disadvantage of this method is that the "Mail to:" field 
contains the email addresses of all recipients, so each recipient knows the 
addresses of the other, which is maybe not always what you want. I put a new 
option to discard the "Mail to:" field, but some systems the consider the 
mail with a missing "Mail to:" field as spam mail. 2.2.5 will be released in 
a couple of days.

> 2600 entries is too much for this application as it load the all files 
> in computer memory
> expand the server memory
> Are you running on linux or Windows ? I suggest linux (faster)
> We are working on the C source to move all data from flat to database like 
> SQL or mysql
> when a parameter flag like 'status' = "OK" for instance
> I suggest also to split in several logbook
> but this is depend on your 'ELOG' parametrisation and logics
> 
> If your data are not 'sensitive' I can check on my linux server
> 
> Etienne

It is not correct that all files are loaded into memory. Only the index 
resides in memory, the data stays on disk. In my environment, I see no speed 
difference between Windows and Linux. Moving to SQL will certainly not speed 
up the responsiveness in my opinion. So before working on that, create a SQL 
database with your 2600 entries and see how fast you can make queries on 
them.

The problem with the slow response is new to me. Other users mentioned no 
problem with logbooks with several throusand entries (except for the "find" 
command). But I will have a look myself in the next feature and see if I can 
make things better.

- Stefan

> I have some problem with email notification
> for some logbooks I would like to notify only to specific adress
> I try
> Email All = adress1, adress2
> 
> Elog send well at 'adress1' and 'adress2' 
> but also to all of other users ?
> how to restric these only to 'adress1 and adress2 ?

Some implementations rely on the fact the email is sent to all users plus a 
few other addresses. What I can do is put in another flag like "Supress 
email to users = 1" which would satisfy both requirements.

> is it possible to notify according to attribue value like
> 
> Attributes = Test1, Test2
> Email All = $Test1
> 
> or concatenation of  $Test1 + '@mba.be' for example

This is not possible right now, but I can put it on the wishlist.

> to improve documentation : true example are missing too much 'theorie'
> but when I'm finish I'll put true sample on the net 

I fully agree, so if someone has nice examples, I'm delighted to put them 
into an "examples" section of the documentation.

- Stefan

> if you are guest in the find option  
> 
> select 'all logbook'
> 
> it will display all 'attributes' from other logbook 
> with no option  'guest command ...'
> but having the same 'attribute' name
> 
> Solution :
> **********
> I use the copy to command to make a copy to other logbook
> with option 'guest command' enabled
> 
> in this section I remove some field so the guest user can't no see all field
> 
> I suggest to give acces to 'guest' on a second run of elog to another
> port or other computer ?

I see your problem. I could either disable the "Search all logbooks" switch 
for certain logbooks (like the guest one), or restrict the search to logbooks 
which have a "guest command" option. What would you prefer?

- Stefan

> > if you are guest in the find option  
> > 
> > select 'all logbook'
> > 
> > it will display all 'attributes' from other logbook 
> > with no option  'guest command ...'
> > but having the same 'attribute' name
> > 
> > Solution :
> > **********
> > I use the copy to command to make a copy to other logbook
> > with option 'guest command' enabled
> > 
> > in this section I remove some field so the guest user can't no see all 
field
> > 
> > I suggest to give acces to 'guest' on a second run of elog to another
> > port or other computer ?
> 
> I see your problem. I could either disable the "Search all logbooks" switch 
> for certain logbooks (like the guest one), or restrict the search to 
logbooks 
> which have a "guest command" option. What would you prefer?
> 
> - Stefan

may be add a parameter

Restrict Search all logboog = 1 or 0
if 1 the switch will not appear 

> Was wondering if there were any tweaks/suggestions for improving the 
> logbooks responsiviness.  Our logbook was started 31 July 01.  Since that 
> time we have went from 1 logbook to 4 logbooks.  Logbook 1 having 2651 
> entries, logbook 2 having 300 entries, and the last 2 are new logbooks, so 
> only a few entries.

In Version 2.2.5, the responsiviness to large (>1000 entries) logbooks has 
been improved dramatically. If no filtering is applied, a page from the 
logbook listing should be displayed with a response time independent of the 
logbook size (I tried 8000 entries). Only when a filter or sort option is 
applied, all entries have to be searched which takes ~5sec for 8000 entries 
on a 1.2 GHz Windows XP Laptop, which is the same speed as before.