We have developed a Sharepoint 2010 Visual Web Part.

This web part adds some extra functionality to Sharepoint but depends on a custom database we've created to index some stuff in a scheduled job. Each Sharepoint Site has to have its "index database". So we need a way to tell the web part what is the connection string for the current sharepoint site (current context).

We have .NET experience, but very little knowledge of Sharepoint and web parts.

What is the best approach to accomplish this? Any suggestions are welcome



Thinking a little bit, I'd like a way to define custom properties (just like a connection string) during the installation of the webpart (I haven't got to this phase yet, but I've been reading this can be achieved using some Powershell commands right?)

So, is there a way to define custom properties during webpart installation, so I can have a different set of properties depending on the SP Site the webpart has been installed

3 Answers 3


The title of your question implies that you want to configure the connection string for each web part. To do this, you should add a web part property to your webpart. Then the user that adds the web part to the page can fill in the value for the connection string. I assume you have a user control for your web part, so just assign your web part property to a public property on your user control before adding it to your controls collection. Then, you'll have access to that value in the Page_Load of your user control.

If instead, you want to have one connection string stored for the entire site and multiple instances of the web part should be able to access that connection string, you can use SPWeb.Properties. I'm not sure when you want to set this value for your site though. You can read this value in the code-behind for your web part since you have access to the current site that you are on using: SPContext.Current.Web.Properties

  • I guess the second option (SPWeb.Properties) is the right choice because each Sharepoint site has its associated custom database and the no matter how many instances of the webpart are inserted on the site, every one of them should connect to the same db. Anyway I'm thinking of a approach to this, I'll update the question.
    – empz
    Commented May 11, 2011 at 15:30
  • I've ended up using SPWeb.Properties to store the connection string since I don't want to expose it to users.
    – empz
    Commented May 11, 2011 at 19:53

Quite a big question. Here's my take on it. In SharePoint land there is a clean separation between admin level stuff and content level stuff. Admin level stuff is created using features at the farm or web application level. Things like IIS, backup restore, search configuration, etc... Content level stuff is commonly defined in features too, site collection and site level. Lists, web parts, et al.

Your question is interesting since it hits both areas. A connection string is commonly defined as an admin level thing since you do not want users to have to specify locations of databases. A connection string might also contain sensitive data such as passwords.

So, how do you approach this. First question would be how big your solution is. If you are allowed to create admin level content I'd propably take my connection string and use the hierarchical object store to save my connection string using a dictionary. That way you can have more than one connection string defined and have the webpart show a dropdown list of the one that is needed for that instance of the webpart inside the toolpane. This way admins can move servers around and update a single administrative object and not worry about all different webparts that use that connection (a BIG plus).

Next is to not define the connection string as an admin level component but to use content level components. Depending on flexibility and reuse I would then either use - The property bag of SPWeb - A hidden list - A property of a webpart

Note that the first option has really big benefits in terms of manageability and is the one you should be using. For a novice SharePoint crew a bit hard to do though. Get someone to spec this out for you, something that should not take that long. Also, buy a bunch of good books and read up about - web part properties - hierarchical object store (SPPersistedObject) - property bags - security

Hope it helps

  • I've updated my question. Do you know a way of doing what I'm asking? Thanks
    – empz
    Commented May 11, 2011 at 15:35

More native way for SharePoint to deal with external data - is to use Business Connectivity Services (BCS). They are allowed even for SharePoint Foundation 2010. Using BCS, you can create External Lists and operate them almost as with standard lists (with some limitations, however). This will not need any extra webpart, but this can be used only for displaying and editing lists data. I don't know if this functionality will fit your needs, but anyway, I think this will be very useful to learn about BCS, if you haven't seen it yet.

To learn more about BCS, please, check out this awesome article from Zimmergren:

  • I've updated my question. Do you know a way of doing what I'm asking? Thanks
    – empz
    Commented May 11, 2011 at 15:35

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.