We have a system where we are going to programmatically add items to a SharePoint List.

We are concerned about the consistency of information.

Is writing to a list an all or nothing operation? Is there a danger that only half the fields will be filled out? Would placing the operation in a transaction scope help?

2 Answers 2


Before putting any deep thought into it, my first thoughts are there wouldn't be any problems really unless you were writing a lot (>10 items a second?) and doing many reads (>50 a second?) in which case I'm guessing you'd rarely get an accurate number of rows in the list, or you may not return all the current rows properly.

I seriously doubt, however, that you'd miss out fields in a bulk write operation, unless you hadn't sanitized the data and had errors, in which case I'm thinking the entire row write operation would be skipped, but I'm not entirely certain.

Programmatically writing to a list is something I don't often give a second though to (got a lot of confidence in how SP writes to SQL), unless the scenario looks like it'll evolve to something resembling an OLTP system.

  • Have to agree with Jimmy. I programmatically add itmes to a SharePoint List all the time (via workflows and web services) and have never had an issue with data not being written to the list. Jan 5, 2011 at 13:29

I suggest you use SQL Profiler and watch what gets updated when you modify an item in your list. If you have multiple updates, then there is the possibility that if something happens half-way through the process (e.g. hardware failure), your data could be in an inconsistent state.

When people worry about transactional database updates they are talking about the ability of the system to survive a failure occuring during a series of connected operations on the database. If you really need this level of integrity my gut feeling is that a SharePoint List is not the right approach, and you should use SQL Server directly to store the data. You could still expose that data in SharePoint through BCS in addition.

I agree that problems are probably rare, but when you need a guarantee then you need to use database transactions to allow rollback to a consistent state if problems occur, however unlikely.

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.