Re: add a "auto number" culomn in the list.
- From: "Engelbert" <Engelbert@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 9 Nov 2005 07:36:10 +0200
OK. Thanks, Mike. That's clear enough :)
Engelbert
"Mike McIntyre [MSFT]" <mmcintyr@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:6c3b0408699c8c7b2863b82fb35@xxxxxxxxxxxxxxxxxxxxxxx
> Hello Engelbert,
> Yes & no :-) It depends upon the list type. For example, if you create
> just a normal, custom list. You can modify the default view to include the
> ID so that you can see what's going on. If you add a couple of fields
> (type doesn't really matter). If you add #1, #2, #3, etc. Now, go back and
> edit #1. The next ID will be #4. Now, if you create an event item, the
> same does not apply. If you add #1, #2, and #3. Now, go back and modify #1
> (edit the comment field). The next itemID will be 5, not 4. This has to do
> with the underlying implementation of the code.
>
> Does it make sense? Not to me :-)
> Is it by design? You bet!
> Is it intuitive? No way!
>
> I believe, but have not verified, that calendar items may "enjoy this
> behavior". It should be easy enough to repro.
>
> --------------------------------------------------------------------------------
> Regards,
> Mike McIntyre [MSFT]
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> E> Thanks for spending the time to go through this.
> E> E> Just the final nail in this.
> E> E> Using your example, if the description field of #1 is edited *using
> E> the normal WSS UI* then what you wrote applies ?
> E> E> I.e. it's not only a problem caused by admins going into the
> database
> E> and modifying these values?
> E> E> Engelbert
> E> E> "Mike McIntyre [MSFT]" <mmcintyr@xxxxxxxxxxxxxxxxxxxx> wrote in
> E> message news:6c3b040868ef8c7b269f6da1135@xxxxxxxxxxxxxxxxxxxxxxx
> E>
>>> Hello Engelbert,
>>> The underlying value refers to the value stored in the Lists table.
>>> When
>>> we add a value into a list item, we look up the corresponding entry
>>> in the
>>> Lists table. We pass in, among other things, the GUID for the Web
>>> (tp_WebId) and the List (tp_ID). We grab the value for
>>> tp_NextAvailableId
>>> (underlying value). We increment this and return it back up the
>>> chain.
>>> This is the value that will be assigned to the list item. There are
>>> other
>>> types of "list items" in WSS. One in particular is the event list
>>> item.
>>> Apparently, whenever you modify an event item, it clones the item &
>>> generates a new itemiD. So, if I have event items #1, #2, #3, #4. One
>>> would assume that the next vaue is #5. If I modify the contents of
>>> #1, for
>>> instance I edit the description field, the next available itemID
>>> value
>>> would be #6, not #5. This is not terribly obvious and has been
>>> causing
>>> "mild discomfort" for quite a few users.
>>> I may have mispoke regarding the re-use value (not enough caffeine in
>>> my system). We do not appear to re-use the values. What I meant to
>>> say is that, by default, we appear to generate ItemID values
>>> sequentially. However, depending upon the list type, event items
>>> being the best example, this behavior is not "obvious". The ItemID
>>> values should increase but are not guaranteed to be strictly
>>> sequential.
>>>
>>> We have seen instances where "well meaning" users will modify the
>>> values in these tables (for reasons unknown) and havoc ensues.
>>> Programmatic access via the OM will work properly. Other programmatic
>>> access, T-SQL statements via query analyzer, can cause big problems.
>>>
>>> I hope that clears things up a bit. I've had another Mountain Dew
>>> this morning; so, my eyes, and brain hopefully, are starting to kick
>>> in.
>>>
>>> ---------------------------------------------------------------------
>>> -----------
>>> Regards,
>>> Mike McIntyre [MSFT]
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>> E> Well you know best, but I'm not sure I follow the logic. E>
>>>
>>>>> The ramifications of this being that if that underlying value is
>>>>> changed, either programatically or otherwise, you could end up
>>>>> re-using an itemID.
>>>>>
>>> E> a) what's the "underlying value"
>>> E> E> this
>>> E>
>>>>> Whenever a list item is added to a document library, a stored
>>>>> procedure is called that queries one of the tables in the database.
>>>>> This query returns the next available itemID value. That value is
>>>>> then incremented, and returned back.
>>>>>
>>> E> Seems to indicate 1,2,3,4,5,6 etc. because the next available will
>>> E> always surely be the next number in order. No ?
>>> E> E> Or is it that if you delete a document then it's ID number
>>> becomes
>>> E> available for re-use. This seems unlikely because then you'd need
>>> to
>>> E> retain *all* previously deleted numbers and the largest ID number
>>> so
>>> E> far rather than having a single field containing the next number.
>>> E> E> b) "either programatically or otherwise"
>>> E> E> are you saying that the code written by Microsoft and which is
>>> in
>>> WSS
>>> E> as delivered could do this ("otherwise"), or are you saying that
>>> if
>>> E> some user/administrator writes *their own* code
>>> ("programmatically"),
>>> E> they could mess this up ?
>>> E> E> Surely then it would be their fault if the ID field didn't work
>>> as
>>> it
>>> E> should ?
>>> E> E> Engelbert
>>> E> E> "Mike McIntyre [MSFT]" <mmcintyr@xxxxxxxxxxxxxxxxxxxx> wrote in
>>> E> message news:6c3b040867438c7b1b3dd6f6487@xxxxxxxxxxxxxxxxxxxxxxx
>>> E>
>>>>> Hello Engelbert,
>>>>> Well, it's not strictly autonumber. Whenever a list item is added
>>>>> to
>>>>> a
>>>>> document library, a stored procedure is called that queries one of
>>>>> the
>>>>> tables in the database. This query returns the next available
>>>>> itemID
>>>>> value. That value is then incremented, and returned back. So, while
>>>>> the
>>>>> itemID looks to be autonumber; in actuality, it is not. The
>>>>> ramifications
>>>>> of this being that if that underlying value is changed, either
>>>>> programatically or otherwise, you could end up re-using an itemID.
>>>>> We've
>>>>> seen it happen before.
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> -----------
>>>>> Regards,
>>>>> Mike McIntyre [MSFT]
>>>>> This posting is provided "AS IS" with no warranties, and confers no
>>>>> rights.
>>>>> E> You can use the standard ID field. It's an autonumber.
>>>>> E> E> Just select it in your specification of the View. It's listed
>>>>> E> already.
>>>>> E> E> Engelbert
>>>>> E> E> "amos hchmon" <amoshchmon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>>>>> message
>>>>> E> news:19AA19AB-D0CA-43DB-894E-D1832B022422@xxxxxxxxxxxxxxxx
>>>>> E>
>>>>>>> I want to add an "auto number" column to my list in the team
>>>>>>> site. Did its possible ? because do not exist attribute in the
>>>>>>> "add list". If did, how do it.
>>>>>>>
>>>>>>> thanks for who refer my question.
>>>>>>>
>
>
.
- References:
- Re: add a "auto number" culomn in the list.
- From: Engelbert
- Re: add a "auto number" culomn in the list.
- From: Mike McIntyre [MSFT]
- Re: add a "auto number" culomn in the list.
- Prev by Date: Re: Can we upgrade WSS with SQL Server 2005 - Express edition ?
- Next by Date: Re: Sharepoint Scroll Listings Web Part
- Previous by thread: Re: add a "auto number" culomn in the list.
- Next by thread: Re: add a "auto number" culomn in the list.
- Index(es):
Relevant Pages
|
