Hi,

We have a custom function that performs a MOVE operation either at file-level or at folder level. When we use the function on a massive scale and/or on a set of folders that have many sub-folders and documents, we encounter some situations where the documents could not be moved (since behind the scene, a move is basically a add followed by a delete), there is a bug in the way WSS/MOSS allocate the internal unique ID for a new document/item and therefore, the MOVE operation can not be completed successfully.

Sometimes, the ID obtained by the internal stored procedure of WSS returns an ID that is already allocated (i.e., the ID being retutrned by the stored procedure is smaller than the latest ID allocated for this document library) and therefore, the add portion of the MOVE cannot be completed. From this point forward, you cannot add any new document in the library and worst, since the MOVE operation was not completed, you end up with duplicate documents. We believe that in our case, since we support multiple MOVE operations against the same set of folders, this is what has stress the ID generation logic to a point where the bug shows itself. We probably have to rework our logic but even then, there is still a bug with the ID generation and Microsoft has recognized it.

When we look at our database, the docID increment is not linear; it is exponential and therefore, for a library containing around 50000 documents, the current highest docID is at 1.9 billion, near the SQL limit of 2.2 billion. This bug was also existing in SharePoint 2003 and Microsoft is currently working on a hotfix for this bug but no date has been released so far.

In the mean time, what you could to determine if you have this situation, and most of the time you really can't tell, is the following:

1. Open the dbo.AllLists table within a WSS Content database. This table contains a row for each list/library within the WSS Content database. The following columns are the ones to look at:
1. tp_Title - The Title of the list/library
2. tp_ItemCount - The actual number of items in the list/library
3. tp_NextAvailableID - The ID that should be used for the next item addition. On normal conditions, this should be equal to to_ItemCount + 1

If there is a huge difference between the tp_ItemCount and the tp_NextAvailableID, there is a chance that this list/document library is victim of the bug. Please note that a high rate of DELETE will reduce the tp_ItemCount and will be reflected in the difference; it should not be considered as an error.

Another useful query to perform to confirm a problem with ID generation. Perform this query agains the dbo.AllDocs table of your WSS Content database:

SELECT dbo.AllDocs.DoclibRowId, dbo.AllDocs.TimeLastModified, dbo.AllDocs.TimeCreated, dbo.AllDocs.[LeafName], dbo.AllDocs.[DirName], dbo.AllDocs.NextToLastTimeModified, dbo.AllDocs.Id, dbo.AllDocs.ParentId

FROM [dbo].[AllDocs]

WHERE ListId = 'a list GUID goes here' AND DoclibRowId is not null

This will show you if the ID generation is linear (and correct) for a given list/library and other information for each item in the list.

Hope this will help someone!

DJ Lordee