Using a DataSource in a Data View Web Part (DVWP) in a Different Site in SharePoint Designer 2010

For whatever reason, Microsoft in its infinite wisdom seems to have removed the ‘Connect to another library…’ link in the Data Source Library in SharePoint Designer 2010. Maybe that capability is hidden somewhere else now, but as my pal Chris Givens pointed out the other day in his Missing Features from SharePoint Designer 2010 post, it’s not “findable”.

Fortunately there’s a workaround and all of your 2007 Data View Web Parts (DVWPs) should work in 2010. (At least if this is the only issue!) You can simply add the same line into the DataSource that you would get if you used the ‘Connect to another library…’ link in 2007. The net-net in 2007 is that you end up with the WebPartPages:DataFormParameter named WebURL in your DataSource section. That’s the entire difference in the code if you want to access content in a different site: the WebURL parameter.  By setting that parameter to the relative URL of the site where the content resides, you can access content in any other site with a DVWP, just like in 2007. You just have to do it manually in the Code View.

Here’s an example of accessing an Announcements list from the root site in a SharePoint 2010 Site Collection which resides in a subsite called ‘Marc’. Note that I’ve also switched from ListID to ListName in this example. As long as your information architecture is solid, that switch can be useful to make your DVWP code more readable. It also can make your DVWP more portable to other sites or Site Collections.

<DataSources>
  <SharePoint:SPDataSource runat="server" DataSourceMode="List" UseInternalName="true" UseServerDataFormat="true" selectcommand="&lt;View&amp;gt;&lt;/View&gt;" id="dataformwebpart1">
    <SelectParameters>
      <WebPartPages:DataFormParameter Name="ListName" ParameterKey="ListName" PropertyName="ParameterValues" DefaultValue="Announcements"/>
      <WebPartPages:DataFormParameter Name="WebURL" ParameterKey="WebURL" PropertyName="ParameterValues" DefaultValue="/Marc"/>
    </SelectParameters>
  </SharePoint:SPDataSource>
</DataSources>

<UPDATE date=2012-05-07>

Note that you may also need to remove several attributes in the WebPartPages:DataFormWebPart header. If you are getting an error, check for attributes like this:

ListId="465831c5-3df1-4259-ba87-b9278007aba5" ListName="{465831C5-3DF1-4259-BA87-B9278007ABA5}"

and remove them. Removing these attributes won’t break the DVWP, and will fix the error.

</UPDATE>

Similar Posts

89 Comments

  1. I also discovered last night, that any time I use this method to add multiple web parts to a page, not matter how many, I have to remove all ListName and ListID from each DVWP’s WebPartPages:DataFormWebPart section before saving. If I fail to do this I will get errors when viewing the page.

    1. Bruce:

      Sorry for the delayed reply.

      When you export a DVWP and then import it, there are a few other places in the DVWP where the list GUID can be stored. Sometimes there’s a ListName attribute in the header of the DVWP, for instance. I’ve always had the best luck simply creating the DVWP in the place where I want it to actually be. If I then need it elsewhere, I just copy the code out of the first page and paste it directly into the second page.

      All that said, I’ve never seen the ListID/ListName reversion that you’re describing.

      M.

  2. Thank you for your replies.
    Apparently it is a environment issue. When we exported and then imported the site to the hastily created test server test server, the problems I described , and several others occured regulalrly. When we exported and then imported to the production server, I was able to use this method to fix all of our expected DVWP GUID’s issues, and had no problems. It worked beautifully. The 2 servers were supposed to be set up identically, so I guess soemthing was missed when we set up the test server to check the feasibility of the move we needed to make.

  3. Marc,
    Thanks so much for your article. I’ve found it extremely helpful in my SP development.
    I have a question regrading your note about removing the ‘ListId’ and ‘ListName’ attributes in the DVWP header. Is there anyway to prevent this from happening over and over? After I deploy my DVWPs to a webpart page in SP, anytime an edit is made to that page in the browser I get an error and I have to go back in remove the ‘ListId’ and ‘ListName’ attributes in SP Designer.
    Thanks for your help,
    John

      1. Marc,
        Thanks for the quick reply. I’m using DVWPs on a subsite that are referencing list data on the parent site. I create/design these DVWPs just like you recommend in SP Designer on a test page in the parent site. Then I copy the code to a webpart page in my subsite, add the SelectParameter web url, take out the “ListId” and “ListName” attributes from header, save the page and it works great. Everything works fine until I edit this subsite page in the browser. Then I get the error “List does not exist…blah,blah” and I have to reopen this page in SP Designer and take out “ListId” and “ListName” attributes again (I guess SP re-adds them??) and save page. This happens everytime an edit is made to the subsite page in the browser. Anyway to prevent this from happening? Hope I didn’t confuse you.
        Thanks.

  4. Marc: Have you been able to replicate this (or find another approach that works) in SharePoint 2013? I have had trouble applying these steps in 2013. Thanks.

  5. I’ve been able to make a reusable DVWP but the import only works if the list exists in the site. If I add the WebPart to a page on a site that doesn’t have the list it will error and it won’t let me add edit the WebURL property in the Parameters Editor. Is there anyway around this?

  6. Hi Marc,

    I have my data view webpart in sitecollection1/subsite1, and the list I want as the source is in sitecollection1/subsite2/subsite3. How would I do this?

    1. The below text is populated at the start of the dvwb when I creat it in SP Designer 2010, and connect a list on the same site as the web part. How should this be changed? There is also the part at the bottom of the web part code that looks similar to your code in the article.

      @DataField1; @DataField2;

    2. There is also listed right after the WebPartPages:DataFormWebPart header. Should that be removed?

    3. Another thing haha. Sorry for the many posts.

      Right after the WebPartPages:DataFormWebPart header, there is a
      “ParameterBinding” that has information for the source list the data view web part is connected to. Including: Name=”ListID” Location=”None” DefaultValue=”{GUID}”

      Should this be removed or updated?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.