I have a question about ELOG. Let's say after the user finishes his shift 
and passess on to the next user on duty. A staff member would want to look 
through the entries and vet them. The staff could lock the entries to 
maintain integrity of the information. How can that be done with ELOG? Can 
you enlighten me. Thank u.

Is is possible to postdate the Entry Date for an entry?

The documentation lists the ability to forward date an entry, but I don't 
see any ability to backdate an entry (edit the date to a date in the past).

Given that the entry date is part of the logbook entry file structure, it 
wasn't obvious how to make this change.

thanks

fred

Just upgraded (using rpms) elogd from 2.3.5 
I am running on RH 7.3

I noticed that my custom start page did not display the Welcome title icon.
It worked fine in prior elogs.

Here's the syntax of the config file:

Welcome Title = <img src="thumb.gif"><p><font size=4 color=white>Elog</font>
Resource dir = /usr/local/elog/


"thumb.gif" is located in /usr/local/elog, and is readable by all.
I also tried the full file name in src= 
<img src="/usr/local/elog/thumb.gif">  - same result.

any hints?

> > I noticed that my custom start page did not display the Welcome title icon.
> > It worked fine in prior elogs.
> > 
> > any hints?
> 
> Indeed there is a bug, it has to do that some icons wnt into the themes 
> directory and are served now from there. So the bug will fixed in the next 
> version (the fix is already avaliable from CVS). As a temporary workaround 
> you just move your image to the themese/default/ directory and it should 
> work.
> 
> An absolute path like /usr/local/... does not work, because this would open 
> a security hole (someone could access any picture on your computer just by 
> requesting an absolute path in the URL), so I removed that option from the 
> software and the documentation.

I did the work-around (moving icon to theme/default) and it worked. Thanks.

Now if you just port elog over to an apache and mysql enviroment, it would be
perfect! 

Announcing:  elog2sql

elog2sql was created to help translate logbooks created by the program
``elog'' from the native elog flat file format to a MySQL database.  I had a
need to have the elog data in a database, and it appears from the forum that
several others had a similar need.

 I created a set of perl scripts that will allow the translation of elog
logbooks into a MySQL database. The design and implementation of these
scripts are a simple one, and allow the one-time copying of a set of logbooks.

The elog2sql toolkit consists of two scripts. The first script, parsecfg.pl,
reads a elogd.cfg, and creates a sql file that will create a set of db
tables corresponding to elog logbooks. The second script, parselog.pl, takes
a set of elog logfiles, and creates a sql file that will enter the logbook
data into the database. The result is a copy of the elog logbook that can
used as desired inside the framework of MySQL. Attachments are handled by
inserting an entry of the attachment name into an seperate attachment table.
This allows multiple attachments per entry.

You can download the elog2sql program archive at
http://www.davidfannin.com/elog2sql/elog2sql.tar.gz . It contains the
scripts and basic documentation.  You can read the man page at
http://www.davidfannin.com/elog2sql/index.html 

email for questions or comments.

I have created a javascript to be used as a browser link that allows a one
step cut and paste from a web browser into a elog logbook. 

The intended application is allow a user to do a text selection in a web
browser, then click on a bookmark that automagically pastes the selected
text, the current browser page url, and the current browser page title into
a pre-defined elog logbook.   I do some research where I would like to save
some text from a webpage, but also have a record of where the webpage came
from.  However, you should find that you can extend this script in a varity
of ways for your own application.  

The script is a simple one: it uses javascript in a saved bookmark to get
your selected text, title, and url, and then creates a new browser window
with a elog form, and print the document variables into the form, and then
submits the form to elog.   The key advantage to this approach is that you
can use the "post" command, rather than "get", to submit to the text section
of an elog logbook.  The only way I found now to submit to elog via a
bookmark is using the "get" command, and it doesn't allow entry of the
"text" field, only attribute fields.    

The second major advantage to using POST is that you can submit a much large
quanity of information ; However, some checking on this leads me to believe
that the limit is browser and server depended, so YMMV.  However, a great
discussion on the limits of browsers can be found here: 
http://www.squarefree.com/bookmarklets/browsers.html .

One of the major limits is that IE6.0 browsers have a maxium of 508 bytes
per bookmark - This book runs over 800 bytes, so I suspect tha IE6+ will not
allow it.  I tested the link with Mozilla and Firebird 0.7.

This script will need to edited for you to use with your elog logbook.
The script should be fairly self-explainitory, if you are used to html forms
and have some exposure to javascript.

You will need to modifiy the following fields:

1) in form action = http://<your_domain.com>/elog/<logbook>/?cmd=New
      change the link to point to your specific logbook to be used for entry.

2) the attribute fields need match up with the ones in your logbook.

     The ones listed in the template are Author, Email, Title, and URL.

     If you have fixed fields (like Author and Email), then you can
predefine these fields as shown.  

      I have the page title used as the entry for Title, and the page url is
 use as the URL attribute.

      Finally, I have the text selection used as the entry for the Text field.

      You can add additional fields by creating a new <input ...>  segment
in the script.  For those more clever than me, you can concatinate the
title, url and selection to paste into the Text area as well.  

3) once you have a edited version of the script (make sure you keep it as a
single line), you can then create a new bookmark in your browser, and then
paste the script into the properties->location field (for Mozilla/Firebird)
or the properites->url field (IE).  Give it a good name like "post to elog"

4) once saved, you can then go a web page, select some text, and then go to
your bookmarks and click on the bookmark.  It should then create a new
window in elog with a completed logbook entry.


some notes:

1) again, this may not work on IE6+ browsers due to M$ limitations.

2) You may have to be logged in already to elog for this work - I have not
tested the interaction using a password protected elog

3) You can only post to a single elog logbook - You'll need to have multiple
bookmarks for multiple logbooks.
   

Elog is a great program, but it can be slow.

I noticed that the gcc compiler options in the tarball Makefile were not
conducive to speed.  There, I tried changing the gcc options to:

CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall

for version 2.5.3, the compile worked, and the program appears to work as
normal, but a bit faster.   I have not benchmarked it, but I think it should
offer a nominal increase in speed.

In particular, I removed the "-g" profiling option, which is not needed for
production code, and can be safely removed. In addition, I put in slightly
aggressive optimization settings, so if this doesn't work for you, you can
first try removing the -f setting, and then backing off the optimization to -O2.

Other may want to post other settings that work for them.

> > I noticed that the gcc compiler options in the tarball Makefile were not
> > conducive to speed.  There, I tried changing the gcc options to:
> > 
> > CFLAGS = -O3 -funroll-loops -fomit-frame-pointer -W -Wall
> 
> Thank your for this hint, I changed my Makefile for the production code. However, I
> could not feel any difference between the two options. The real problem is the
> function getcfg(), which gets called many thousand times internally and has to parse
> elogd.cfg each time. Once I implement a hash table for that function, elogd should
> become faster by at least a factor of two.

Yeah - What's up with that?

I have seen this discussed before - Seems like it should be a priority to get this
fixed, as doing a hash table is straightforward, and the speed increase should be pretty
health - there are several c libraries available - check out "man 3 hsearch" for the
POSIX hash table management that already available.  Other c library searches that you
could use include bsearch (binary tree), tsearch (tree searching), btree (b+ tree). 
However, the easiest and most obvious one to use for elog appears to be a simple hash
table search (hsearch).

Is there something else  which is making this difficult to do?