Home/ Questions/Q 8132033
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T09:14:49+00:00

I have done some research and it really seems that implementing a transaction system

  • 0

I have done some research and it really seems that implementing a transaction system based on Sharepoint lists .. is a wrong design decision.

However, I am still of the opinion that you can somehow leverage sharepoint benefits, even for transaction systems. I was thinking of 2 options:
1. Use a separate database and use BCS to connect with the data
2. Just use sharepoint for hosting web parts, all data access and data presentation should be implemented from scratch.

I am a bit curios if there is a good case study of other systems.
For example, I know that Infor is now using Sharpoint. But from what I can understand they just use the concept of webparts (as point 2 above). All data would be stored in the Sun database. and even the screens seem to be custom built. And I don’t know if they use BCS in any way. However, they have used Sharepoint webparts very well to build a dashboard like experience.

Any assistance would be greately appreciated. I would need example of case studies to support my argument that sharepoint is viable for transactions systems. And perhaps any ideas/tips/pitfalls when implementing a transaction system on sharepoint.

Edit – these are some pain points that I have found in Sharepoint when used for Transactional systems.

1. You cannot use transactions. If you update multiple lists – you cannot do this in one atomic transaction.
2. The abstraction layer between Sharepoint and SQL means that you lose several benefits that SQL has to offer. You cannot create stored procedures because you should work with list. You cannot work directly at the database level because you should pass through Sharepoint. Some optimizations cannot be applied.
3. Joins have some limitations in Sharepoint. This greatly limits your analytical possibilities.
4. Sharepoint stores your data in one table which causes a number of issues. You cannot optimize that much.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It really depends on what specific application you’re planning to create. You can still use SharePoint as a front-end for any web based applications and just create custom web-parts like you mentioned.

    You can use lists as tables to an extent. From SharePoint 2007, Microsoft mentioned some limits for 2010 and 2007 per list before performance issue is noticed.

    Other things I can think of is being able to use SharePoint workflows and e-mail notifications based on certain things done in your application. You can create a simple audit trail list as well and when an error is logged an e-mail will be sent to you or your team.

    It really all boils down to what specific application requirements you need. You can update your post and I’ll try to help you as much as I can. 🙂

    • 0