Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have my custom list instance which had 3 items initially. Their ID are 1, 2 and 3. The list instance was declared in XML and was automatically created during deployment. After the deployment, I manually added one more item which had ID=4. Then I received a request to improve the XML declaration of the list instance by adding an item with ID=4 into the declaration to deploy it automatically during next deployment. I removed the item with ID=4 which was added manually from the list and put corresponding elements of the item into the XML declaration.

Unfortunately, when I deploy my updated list instance, which now have four items, the forth item is not added into the list instance. If I change ID of fourth item from 4 to 5, the list instance is deployed successfully and a new item with ID=5 is created.

Could you assist me and tell me what should I do me to solve the issue to have four items in my list instance with the following IDs: 1, 2, 3 and 4.

Note: I know that I can remove the list and reactivate feature which is responsible for the list instance. I cannot use this way, because in real life the list instance has 500 items. The items have data translated by foreign editors. I, bassically, will not be able to restore the same translated values automatically. Doing it manually is nightmare.

Thank you.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

SharePoint assigns the ID sequentially and if you delete the items from the list, SharePoint does not reuse the ID of deleted item again.

The only option is to delete and recreate the list.

share|improve this answer
    
Thank you for your answer. I have added my note, probably after you provided the answer. So there is no way to solve my issue. Can I somehow set "current" ID in the sequence to 3 in my example to let SharePoint know that nex ID should be 4? –  Antipod Feb 25 '12 at 18:13
    
I don't know if there is any reliable way to do that. Check some related answers: sharepoint.stackexchange.com/search?q=list+id+sequence –  Ashish Patel Feb 25 '12 at 18:51
1  
Ashish is right. You should not try to force IDs and you should not rely on them having a specific value in your processing nor try to provision lists with specific IDs. What is the reason that you want your item to specifically have ID 4? I smell a design flaw :(. You will most certainly encounter a number of correlation issues if you rely on forced IDs to establish relationship. You're not saving yourself any manual work, just postponing it... Use a custom key instead, one that you can control entirely. –  Louis Feb 26 '12 at 18:20
    
Thank you Louis. I have found that AllLists table in my content database has column tp_NextAvailableId where I see value of my next ID in the list. I probably can change it using UPDATE statement, not sure that it is safe though. Will it break something? Is it allowed to do? –  Antipod Feb 27 '12 at 12:28
    
I would refrain from updating content database directly. Microsoft may not provide support for your application in future if they figure that out. –  Ashish Patel Feb 27 '12 at 20:19
add comment

The problem here is that SharePoint will not "see" the changes made to your listinstance XML definition. This is basically the case with anything created "declaratively", i.e. from XML.

Take for instance an XML schema, aContent Type definition, changing the content type schema XML (by say adding or removing a fieldref) will not change anything in the actual content type that that definition created in your site. (only the rootweb will reflect the change, any list using the content type won't)

This changing of an XML declaration is actually unsupported, because it creates a discrepancy bewtween the schema of the actual content type / field / list definition / site definition. The reason for this is that as soon as your content type / field / list def. is actually used, SharePoint will make a copy of it; this is called ghosting.

Another scenario entails 1 off items, things that are created once based on an XML declaration in a feature (in this case a list instance). Once created, SharePoint will not reflect any changes made to the XML (i.e. adding or removing list items through that XML), For All SharePoint knows, there is a listinstance at the url specified in the list instance XML, so it can't create a list there anymore and thusly will skip processing the listinstance xml.

I'd say that pretty much the rule of thumb with declaratively deploying to SharePoint is: Once created (the XML) and used (i.e. the site is live), don't change it. Any change you need to do should be done either as a featureupgradeaction (SP2010), or if that is to limited (or you are running SP2007), a feature receiver.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.