|
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? |
|||
|
|
|
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. |
|||
|
|
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. |
|||
|
|
