I need a field that automatically increments by one each time a document is added to a library. I have found some awkward work-arounds where a workflow gets a number from a list and adds one and creates a new entry in the list with the new value. The guaranteed concurrency errors this will create are silly at best. In pure DotNET I'd simply use a database sequence, query NextVal and the database handles record locking so even documents added at the exact same second get different numbers.
How do I do this with SharePoint 2013 and/or Nintex and where is it documented?
Solved! Go to Solution.
By default on Sharepoint in lists or libraries there is a column named ID, that is autonumeric.
If that column is not useful for you you could use a Library with a new number column.
Then when you want to increase it , you can check out the document, increase the number and check it in
You 'd also use the action "wait for checout status change".
I'm required to use a sequence of numbers starting from where a previous sequence ends so I need to be able to set an arbitrary starting number. Once a document has an assigned number, that number won't change, even for new versions. Is ID the only auto-numeric field available in SharePoint/Nintex? I don't see a way to create a new auto-number column under create column.
This kind of thing is ridiculously easy in SQL Server and DotNET which SharePoint are built on. Do I really need to create a sequence on the SQL Server and run a database query just to duplicate functionality that has existed in Microsoft products for decades?
Your suggestion of creating a new list or library with all the resulting use of resources and overhead, checking an entry out, changing it and then checking back in does avoid concurrency errors. It really seems like a serious Rube Goldberg machine though. I'll do that if I have to but I would prefer doing things a lot more cleanly and see no reason for a whole new list/library to be required.
Thanks for the reply.
Posting on the Microsoft SharePoint forums under MSDN it became pretty clear that the only alternative is to create an auto-number or Identity field in SQL Server and having a set of stored commands to interact with the field value. The amount of effort turns out to be pretty much the same as the list that stores the single numerical entry and modifies it by workflow. Thank you Fernando for providing what turns out to be the best solution.
I guess I'm spoiled by using more mature database products than SQL Server.