We have an auto-incrementing reference attribute defined as:

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute.  Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the  $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out.  It looks as if it might be because multiple people are adding entries concurrently.  Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated?  Here is a list showing the discrepancies.

Date        Item     Time Stamp (from the line after $@MID@$)  "Created" attribute time stamp

22/09/08    124      16:15:10                                   11:58

22/09/08    125      16:33:54                                   16:24

22/09/08    125      16:35:37                                   16:33              Should be 126

...

10/10/08    146      10:39:09                                   10:30                    Correct

10/10/08    146      10:46:57                                   10:35              Should be 147

10/10/08    147      13:04:03                                   13:02              Should be 148

10/10/08    148      15:11:38                                   15:00              Should be 149

...

17/11/08    171      10:21                                      10:17              Correct

17/11/08    174      14:30                                      13:47              Should be 172

17/11/08    175      16:14                                      16:04              Should be 173

17/11/08    176      16:49                                      16:38              Should be 174

...

25/11/08    187      15:49:58                                   15:47              Correct

25/11/08    187      15:52:39                                   15:48              Should be 188

25/11/08    188      16:49:56                                   16:44              Should be 189

25/11/08    188      16:52:40                                   16:40              Should be 190

25/11/08    188      16:55:17                                   16:43              Should be 191

Let me know if you need any more information.

regards

Steve

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

Hello,

I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.  

Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.)

1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer.

2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.  

2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such.

2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.

All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.

To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder.

However, I can't commit myself to always create a log entry for every day either.  Again, human error.

Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end-of-day or on a day I have downtime and can commit to administrative work.

My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.

Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?

Thank you very much in advance!

Actually I would not worry with the 042313a.log files. In a future version of elog they might be replaced by a database or so. I see two options:

1. Add an attribute of date/time type. You do that with "Type <attribute> = datetime". Then you can assign a certain date or time to each entry you do. That means you can tag an entry with the date of yesterday or so. If you make that date then the main database key (via "List display") it basically replaces your "internal" date.
2. You can do automatic entries with the "elog" utility coming with the distribution and described here. This you can even run from a cron job. If you submit a new entry from elog, you get automatically the incremented IDs etc. You can use some default values for the attributes, which you can change later.

Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!

 Purists look away now.

I have the same issues regarding "catching up" of entries.  So what I do is use the date command to reset the computer's time back to the time that the entry [i]should[/i] have been made.  Say I need to put an entry for last Thursday (today is Saturday 27th),

Firstly I set the clock back by

date 04252200

(I use a time of 22:00 or later as code for a retro-made entry, the date being the important point for me).

Then any entry will have the correct time (sic) and date entry within the file, and the file the expected format of 130425a.log

After Thursday's batch of entries, I then simply reset the clock for the next entry/ies or indeed back to real time.

Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!

---

Nice to meet someone else who gets down to the bare ascii and knows how to edit the xxxxxxa.log files!