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...