Issue list ID's

[Dave Slinn]

We've recently rolled out a customized issue list to manage our IT support
area, and we've noticed a peculiar behaviour. When a new item is saved, the
ID value created is not necessarily the next one you'd expect. There are
"gaps" in the numbering, meaning you can have Issue IDs numbered {1, 2, 5,
8, 12, ...}.

From what we can gather, this is because every time you edit an issue, it
maintains a history for each item, which for some reason takes that next ID
value, even though the editted item's ID is unchanged. What you ultimately
end up with is the appearance of "missing" issues (even though they never
existed in the first place) and you Issue ID's increment much more rapidly
than you expect, especially if each item goes through several revisions.

Is this behaviour experienced by everyone? Doesn't it seem strange that
sharepoint doesn't use the next logical Issue ID, MAX(int1) + 1, instead of
just the next tp_ID, since tp_ID is used for each revision instance?

[Bil Simser [SPS MVP]]

This is by design Dave. While it may not be the best of design, it's not
a guffaw or anything. SharePoint just uses the next ID number and both
the original issue items and each edit use the same thing. Just one of
those quirks that makes it that much more fun to mess with.

--
Bil Simser
SharePoint MVP, BSc., MCSD
Calgary, Alberta
http://weblogs.asp.net/bsimser

"Dave Slinn" <Couga...@noemail.noemail> wrote in message
news:utnlcVky...@TK2MSFTNGP14.phx.gbl:

[Wei-Dong XU [MSFT]]

Hi Dave,

The ID generation algorithm in Sharepoint is not public. As I know, the
algorithm may be related to the save time and other considerations. So this
is what you have found that the ID will not be incremented by one. From my
view, since ID is only used to identify the item uniquelly, this should not
be a problem for our usage and development on Sharepoint.

If currently this affects to your development, could you be so kind to tell
me more regarding the scenario? I will be glad to be of any assistance on
this matter.

Expect to your update!

Best Regards,
Wei-Dong XU
Microsoft Product Support Services
This posting is provided "AS IS" with no warranties, and confers no rights.
It is my pleasure to be of assistance.

[Dave Slinn]

No, you are right - it will not cause any problems. It just was unnerving
in the beginning when we rolled out the list for public use and we saw these
gaps. Our first inclination was to think that something was wrong with the
form we created and that there was an error during the save of new items.
When we looked in the table, we saw every row, in order, without any missing
records, so then we figured there was something wrong with the views we
created - we thought maybe they were filtering records for some reason.
After a bit more dissection of the table, we realized that this is how it's
supposed to work.

Again, it's not an issue and we can accept that - it just set our IT team
back a bit. We thought we had a much bigger problem...

Thanks for the input.

"Wei-Dong XU [MSFT]" <v-w...@online.microsoft.com> wrote in message
news:OHjhTkky...@TK2MSFTNGXA01.phx.gbl...

[Nuraan]

In my organisation we use a similar list and I've also come across this
issue. However, my conclusion to how this happens is different to Dave's.

As the ID column is a default column, it increments each time a new record
is added to a list. As a result, if you add a new record then delete it, you
will no longer see that ID number and the next record added will just
increment. This is because that record is not completely deleted from the
server, but only from the list's view.

That's my assumption at least - is that about right?

Dave, if you do want a workaround solution, I've found that you can simply
add in your own column as a number or calculated field (but you can't name it
ID of course), then remove the ID column from the list's view. This should
increment properly.

[Wei-Dong XU [MSFT]]

You are very welcome! Please feel free to let me know if any question on
the WSS.

Enjoy a nice weekend!