0

I would like to programatically(C#) export all properties of all my webparts from Sharepoint 2013. I have access to SP content db and I wonder whether it is possible make use of it somehow (for example deserializing [tp_AllUsersProperties] column).

I know I can do it by creating each webpart and reading its properties but it can be a long process.

I did some research and I found that there is (but unfortunately internal) class BinaryWebPartDeserializer. (https://pholpar.wordpress.com/2010/10/17/decoding-the-content-of-the-binaryserializedwebpart-the-theory/)

I also found this post: https://zetitle.wordpress.com/2010/08/25/how-to-read-webpart-properties-from-the-database/ but it looks far too easy. I would rather prefer to use some SP API.

Do you know any reliable idea? Anything you can recommend?

Szymon

Improve this question
6
  • About direct querying: 1) This is completely unsupported by the EULA you agreed to when you installed SharePoint. 2) Your queries are not guaranteed to work after applying any patches or service packs to SharePoint since Microsoft could change the DB schema anytime. 3) Directly querying the DB can place extra load on a server and hence performance issues. 4) Direct SELECT statements against the DB take shared read locks at the default transaction level so your custom queries might cause deadlocks and hence stability issues. 5) Your custom queries might lead to wrong data being retrieved.
    – Marcelo Espinosa
    Commented Nov 15, 2016 at 15:42
  • @MarceloEspinosa, too much negativity in your comment :) The query wouldn't be supported, but once again - @Knopo probably wouldn't need Microsoft to support it. It's not like he would loose support for SharePoint because of running a select query on a database. If a support case arises, the only thing you need to do for Microsoft to continue with the support case is "stop custom select queries running against the database". Another thing is that running stored procedures, which are documented is supported - read more here support.microsoft.com/en-gb/kb/841057
    – Paul Strupeikis
    Commented Nov 15, 2016 at 16:03
  • @Knopo, just run the query with NOLOCK or READUNCOMMITTED and you'll be fine. I believe the chance of anyone adding a web part or changing its properties at the same time you are running that SQL query is quite low :) @MarceloEspinosa, one more things - its the CHANGES (not all, tho) to the database that are not supported, and not direct querying. But I would agree, there are other ways to achieve the same, which might be more appropriate. I would personally go for a PowerShell script.
    – Paul Strupeikis
    Commented Nov 15, 2016 at 16:05
  • @PaulStrupeikis thank you for your answer. I do not worry about locking because it is kind of one-time maintenance - I can assume that I will be the only one who will use DB. However the problem is understanding the data that is stored in DB.
    – Knopo
    Commented Nov 15, 2016 at 16:08
  • @Knopo, you might not be worried about locking, but what if a SharePoint process tries to access that locked data at the same time as you running that query? It's not just users getting data from the database (indirectly, obviously), but many SharePoint processes run constantly, i.e. timer jobs, etc. And these might get locked out. What would then happen? Probably nothing, but still, just to be on the safe side :)
    – Paul Strupeikis
    Commented Nov 15, 2016 at 16:10

1 Answer 1

Reset to default
0

There is nothing reliable when querying a SharePoint content database directly, but if you are doing that then run your queries with NOLOCK or READUNCOMMITTED to prevent locking.

Improve this answer

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.