Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG  Not logged in ELOG logo
 Back  |  Find  |  Login  |  Help 
icon1.gif   Auto-increment attributes, posted by Steve Williamson on Wed Nov 26 10:00:25 2008 
    icon2.gif   Re: Auto-increment attributes, posted by Steve Williamson on Fri Dec 5 16:14:19 2008 
       icon2.gif   Re: Auto-increment attributes, posted by Stefan Ritt on Mon Dec 8 10:09:14 2008 
          icon2.gif   Re: Auto-increment attributes, posted by Steve Williamson on Mon Dec 8 13:13:13 2008 
Message ID: 66097     Entry time: Fri Dec 5 16:14:19 2008     In reply to: 66081     Reply to this: 66100
Icon: Reply  Author: Steve Williamson  Author Email: StephenWilliamson@Barnsley.gov.uk 
Category: Bug report  OS: Linux  ELOG Version: 2.7.5 
Subject: Re: Auto-increment attributes 

Steve Williamson wrote:

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

 Hi

This is to let you know that the increment problem has just happened again.

Item 206 has timestamp (from the line after $@MID@$) of 11:59:45 and "created" attribute timestamp of 11:29

overlapping with this, a second item 206 has timestamp of 12:04:02 and "created" attribute of 11:53

So, both users were entering information between 11:53 and 11:59:45 and both picked up the same increment number.

There's no easy solution tho, is there? If you pick up the increment number at the start so it can be displayed on screen and ensure uniqueness then, if a user cancels a new entry you end up with "holes" in the sequence.  If you pick it up at the end then you can't display it until the user presses submit.

regards

Steve

ELOG V3.1.5-2eba886