1

The problem I have is simple but I can't seem to figure out how to fix it.

I have a workflow that copy's an item to another list once a column is set to "Yes".

The ID will then change to suit the new list which I know you can't change. I wanted to know if it was possible to have a column that displays the "old ID" from the previous list?

Improve this question

2 Answers 2

Reset to default
0

The only way is when doing backup/restore process eg. through PowerShell (Export-SPWeb and ImportSP-Web commands).

You cannot manage this by workflow, or code. The workaround is to create your own ID field/column which you will use in your applications instead of SharePoint internal ID.

Improve this answer
6
  • Thanks for the answer. Unfortunately I don't have access to PowerShell. Would it be possible to have a column that pulls the ID from the ID Column and saves it as a text/string in a new column as this would solve my issue?
    – stackchris123
    Commented Feb 10, 2015 at 9:58
  • You can create your own "ID" column (for example "MyID"). But you can't change value in standard ID column.
    – BioGeneZ
    Commented Feb 10, 2015 at 9:59
  • How would I go about creating my ID column as I would need to ensure it auto increments and still says the same once it is copied to the new list?
    – stackchris123
    Commented Feb 10, 2015 at 10:06
  • You can create a small WF and apply it to the ItemCreated event. There, you will handle this autoincrement behavior. Or, as I understood, in the list B where you copy the items are items created only by workflow. So in list A you can use SP ID and in list B use myID where you will just copy the value from ID column in list A.
    – luccio
    Commented Feb 10, 2015 at 10:09
  • "you can use SP ID and in list B use myID where you will just copy the value from ID column in list A" How would this be done?
    – stackchris123
    Commented Feb 10, 2015 at 13:20
0

Chris,

There is a way to set an ID value, but there are risks involved, since you need to query the database directly. Yes yes, SharePoint geeks and cracks will go NO NO NO, but since you're not changing the DB schema you're all good. Let me explain why it's safe:

  1. Microsoft doesn't recommend querying the Content database directly since it might void the warranty. This might happen if you go berserk with UPDATE TABLE and DROP VIEW SQL queries. While you're not changing the schema, you're fine. Microsoft tools that check if the warranty is void check database schemas and not the content.
  2. All content migration tools from Metalogix, Dell, AvePoint etc. allow you to tick a box called "Preserve Item IDs". There is no magic involved - they all query the Content database and set NextAvailableId. If that would void the warranty, most of the migrated SharePoint farms would end up not being supported by Microsoft? I hardly doubt it :)
  3. This is not a valid point, but still - sometimes you just can't get over a problem without messing up with the Content database a bit. See this.

Anyway, if you decide to go for it:

In your workflow code you need to do some SQL magic before copying the item to your new list:

UPDATE ContentDB.dbo.AllListsAux set NextAvailableId='1' where ListID='GUID'

This way you can set the ID of the next item that will be added to the list. This could be a solution if the items are not added to the list in any other way except by that single workflow. If not, you'll end up having a small issue. Eg.: you have items with IDs 1, 3, 4 and 5. You set NextAvailableId to 2 and insert an item. You end up having items 1, 2, 3, 4 and 5, but NextAvailableId is incremented by one (which means it would currently be set to 3). If you add an item and click Save, the item wouldn't be saved but the NextAvailableId would still be incremented by one (leaving it at for). So you would need to click Save button 2 more times so the NextAvailableId is set to 6. Only then you will be able to save the item.

Otherwise just go for a custom number column and assign old ID to the new column.

Hope this helps!

Improve this answer
2
  • 1. true, it is not recommended and can void warranty 2. MS has no chance to find out you are using some tool which is not deployed to server, but can check the WF/solution you have in your farm - there will be DB call, update -> bye bye warranty. Sure, the worst case scenario but I cannot recommend accessing the DB directly. This is not one-time migration, but WF which makes huge difference.
    – luccio
    Commented Feb 10, 2015 at 13:25
  • They won't void the warranty if you are doing CRUDs. The thing you can't do is change the db schema (tables, functions, procedures etc.). I don't see a problem with querying the database even 100 times a day. If one time is fine, a 100 times is fine as well :)
    – Paul Strupeikis
    Commented Feb 10, 2015 at 13:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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