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

We want to synchronize data across several environments that are not production, ie dev, test ect. We have several list that are set to order by ID. The problem is that when doing the content deployment the ID's are not kept in sync across environments which causes the data to not display in the expected order. Is there a way to reseed the ID's in the receiving tables to match the record being inserted?

share|improve this question
add comment

3 Answers

up vote 0 down vote accepted

Thanks for the responses guys. As the Content Deployment is a requirement across several version of the production site as well a db restore is not a valid solution for us. What I ended up doing was creating an additional column in the list to support sort order (int), then wrote n OrderBy query in CAML to sort by that column. This was where I was trying to go to begin with but for some reason the way my access in the Site Admin was set up limited what actions I could take on that column. We ended up getting that prepped and the query works great.

share|improve this answer
add comment

The best way I've found to do this is to periodically copy the content database itself back down from Production and attach copies of it to each of the environments. This is very simple to do but does have a few potential drawbacks, such as:

  1. Any manual changes to the dev/qa environments are wiped out (if you are using features to deploy customizations this should not be an issue)
  2. Dev/qa content is replaced which can lead to a potential loss of test data
  3. The production database is often very large and can eat up precious DB space on the typically spartan dev/QA database servers
  4. You MUST be using the exact same version of SharePoint in each environment

That said, it has some very strong points as well

  1. Developers are testing against real-world data which means that they can test against situations that would be extremely complex to manually replicate
  2. Fewer surprises as code is moved through environments since it is effectively developed in "production"
  3. All internal IDs exactly match in each environment making it much easier to move ID-bound components (i.e. many webparts) from environment to environment
share|improve this answer
    
Good points. I would put the version requirement as a strong point - unless you are in fact testing an upgrade. But even then, you restore it before the upgrade process anyway. :) –  Russell Jun 7 '12 at 6:09
add comment

In SharePoint list ids only remain the same if the lists were created declaratively (ie defined in XML in a feature).

If the lists are created through the UI, in script, or programatically they will get a new id in the import destination. It's a big plus for defining lists (properly) in features.

I think.

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.