Contents tagged with Database

  • A Tour of SharePoint Data Source Controls

    Introduction

    Besides the classic ASP.NET data source controls, SharePoint brings along its own. These allow us to retrieve data not just from SharePoint, but also from external sources, such as web services or SQL databases. Using SharePoint Designer you end up using these data sources without even knowing, and, specially, ignoring what other options you have. Let’s look at these controls one by one and see how the can be used. I already talked about the SPDataSource and AggregateDataSource, so I won’t cover these here. I also won’t be covering them in depth, but instead will provide an example of how to use them.

    SPHierarchyDataSourceControl

    The SPHierarchyDataSourceControl allows us to retrieve data (documents, list items) hierarchically from either a site or a list. It can only be bound to a control that can display hierarchical data, such as the SPTreeView control. It cannot be easily customized, except by using CSS and JavaScript.

    A simple example is:

       1: <SharePoint:SPHierarchyDataSourceControl runat="server" ID="hierarchy" RootContextObject="Web" ShowDocLibChildren="true" ShowListChildren="true" ShowFolderChildren="true" ShowWebChildren="true"/>
       2: <SharePoint:SPTreeView runat="server" DataSourceID="hierarchy"/>

    BdcDataSource

    A BdcDataSource let’s you retrieve data from a BCS data source (external content type). This may happen when you don’t have an external list created or you want to call a specific finder method. You need to specify the namespace, LOB instance, entity, and finder method. If the finder needs parameters, you will need to supply them. It can be customized by hosting it in a DataFormWebPart and by applying XSLT.

    Here’s an example:

       1: <WebPartPages:DataFormWebPart runat="server" Title="BCS" DisplayName="BCS" ID="bcs">
       2:     <DataSources>
       3:         <SharePoint:BdcDataSource runat="server" Mode="List" EntityName="Parent" LobSystemInstanceName="BCS" EntityNamespace="http://sp2013" FinderName="Read List"/>
       4:     </DataSources>
       5:     <Xsl>
       6:         <xsl:stylesheet version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">
       7:             <xsl:output method="html" indent="no"/>
       8:  
       9:                 <xsl:template match="/">
      10:                     <xsl:variable name="Rows" select="/dsQueryResponse/NewDataSet/Row"/>
      11:                     Count: <xsl:value-of select="count($Rows)"/>
      12:                 </xsl:template>
      13:             
      14:         </xsl:stylesheet>
      15:     </Xsl>
      16: </WebPartPages:DataFormWebPart>

    SoapDataSource

    SoapDataSource is the control that retrieves data from a SOAP web service. You specify the URL of the web service, the action to call and the SOAP envelope, together with any required parameters. It should be hosted in a DataFormWebPart and can thus use XSLT for the formatting of its contents.

    An example of calling the Lists.asmx web service:

       1: <WebPartPages:DataFormWebPart runat="server" DisplayName="SOAP" Title="SOAP" ID="soap">
       2:     <DataSources>
       3:         <SharePoint:SoapDataSource runat="server" WsdlPath="http://sp2013/_vti_bin/lists.asmx?WSDL" SelectUrl="http://sp2013/_vti_bin/lists.asmx" SelectAction="http://schemas.microsoft.com/sharepoint/soap/GetListCollection" SelectPort="ListsSoap" SelectServiceName="Lists">
       4:             <SelectCommand>
       5:                 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
       6:                     <soap:Body>
       7:                         <GetListCollection xmlns="http://schemas.microsoft.com/sharepoint/soap/"/>
       8:                     </soap:Body>
       9:                 </soap:Envelope>
      10:             </SelectCommand>
      11:         </SharePoint:SoapDataSource>
      12:     </DataSources>
      13:     <XSL>
      14:         <xsl:stylesheet xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ddw1="http://schemas.microsoft.com/sharepoint/soap/" version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">
      15:             <xsl:output method="html" indent="no"/>
      16:     
      17:             <xsl:template match="/">
      18:                 <xsl:variable name="Rows" select="/soap:Envelope/soap:Body/ddw1:GetListCollectionResponse/ddw1:GetListCollectionResult/ddw1:Lists/ddw1:List"/>
      19:                 Count: <xsl:value-of select="count($Rows)"/>
      20:             </xsl:template>
      21:         </xsl:stylesheet>
      22:     </XSL>
      23: </WebPartPages:DataFormWebPart>

    XsltListViewWebPart (External List)

    External lists can be displayed using the XsltListViewWebPart. Nothing really new here.

    A simple example (of course, do replace the list and view GUIDs):

       1: <WebPartPages:XsltListViewWebPart runat="server" Title="External List" DisplayName="External List" ListName="{C9DD692D-27C6-4B99-A197-F8892F293C04}" ID="external">
       2:     <XmlDefinition>
       3:         <View Name="{DDD613DD-BA38-4DBF-9A89-5502B0152EE1}" Type="HTML" DisplayName="Read List" Url="/Lists/ExternalList/Read List.aspx" BaseViewID="1">
       4:             <Method Name="Read List"/>
       5:         </View>
       6:     </XmlDefinition>
       7:     <Xsl>
       8:         <xsl:stylesheet version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">
       9:             <xsl:output method="html" indent="no"/>
      10:  
      11:                 <xsl:template match="/dsQueryResponse">
      12:                     <xsl:variable name="Rows" select="Rows/Row"/>
      13:                     Count: <xsl:value-of select="count($Rows)"/>    
      14:                 </xsl:template>
      15:         </xsl:stylesheet>
      16:     </Xsl>
      17: </WebPartPages:XsltListViewWebPart>

    XmlUrlDataSource

    The XmlUrlDataSource is used for invoking REST web services. Similar to  SoapDataSource, you need to pass it the URL, but also the HTTP method and any parameters. I is also usually hosted in a DataFormWebPart.

    Here’s an example of calling the weather service I talked about in another post:

       1: <WebPartPages:DataFormWebPart runat="server" Title="REST" DisplayName="REST" ID="rest">
       2:     <DataSources>
       3:         <SharePoint:XmlUrlDataSource runat="server" AuthType="None" HttpMethod="GET" SelectCommand="http://api.openweathermap.org/data/2.5/weather">
       4:             <SelectParameters>
       5:                 <WebPartPages:DataFormParameter Name="id" ParameterKey="id" PropertyName="ParameterValues" DefaultValue="2740637"/>
       6:                 <WebPartPages:DataFormParameter Name="mode" ParameterKey="mode" PropertyName="ParameterValues" DefaultValue="xml"/>
       7:                 <WebPartPages:DataFormParameter Name="units" ParameterKey="units" PropertyName="ParameterValues" DefaultValue="metric"/>
       8:             </SelectParameters>
       9:         </SharePoint:XmlUrlDataSource>
      10:     </DataSources>
      11:     <Xsl>
      12:         <xsl:stylesheet version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">
      13:             <xsl:output method="html" indent="no"/>
      14:  
      15:                 <xsl:template match="/">
      16:                     <xsl:variable name="Rows" select="/current"/>
      17:                     Count: <xsl:value-of select="count($Rows)"/>
      18:                 </xsl:template>
      19:             
      20:         </xsl:stylesheet>
      21:     </Xsl>
      22: </WebPartPages:DataFormWebPart>

    SPSqlDataSource

    The SPSqlDataSource is what SharePoint uses to access a SQL database. If you use SharePoint Designer to add one such data source, you might be surprised to see that it places a SqlDataSource instead. The thing is, SharePoint uses ASP.NET tag mapping to replace any SqlDataSource control for a SPSqlDataSource. Again, we host it inside a DataFormWebPart for easily formatting its contents and you can pass parameters to the SQL.

    An example:

       1: <WebPartPages:DataFormWebPart runat="server" Title="SQL" DisplayName="SQL" ID="sql">
       2:     <DataSources>
       3:         <SharePoint:SPSqlDataSource runat="server" ProviderName="System.Data.SqlClient" ConnectionString="Data Source=servername;User ID=username;Password=password;Initial Catalog=database;" SelectCommand="SELECT * FROM [SomeTable]"/>
       4:     </DataSources>
       5:     <Xsl>
       6:         <xsl:stylesheet xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" version="1.0" exclude-result-prefixes="xsl msxsl ddwrt" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:ddwrt2="urn:frontpage:internal">
       7:             <xsl:output method="html" indent="no"/>
       8:  
       9:                 <xsl:template match="/">
      10:                     <xsl:variable name="Rows" select="/dsQueryResponse/NewDataSet/Row"/>
      11:                     Count: <xsl:value-of select="count($Rows)"/>
      12:                 </xsl:template>
      13:         </xsl:stylesheet>
      14:     </Xsl>
      15: </WebPartPages:DataFormWebPart>

    SPCalendarDataSource

    SPCalendarDataSource cannot be used exclusively on the markup, it needs a List property that can only be set through code. It is usually used to populate a SPCalendarView control.

    An example of the markup:

       1: <SharePoint:SPCalendarDataSource runat="server" ID="calendar" ViewType="Week"/>
       2: <SharePoint:SPCalendarView runat="server" DataSourceID="calendar"/>

    Conclusion

    While SPDataSource is generally the most generic and useful control, it cannot do everything, namely, access external sources. For that, we have other options; the AggregateDataSource can be used to bring together data from all of these sources, except SPHierarchyDataSourceControl and SPCalendarDataSource, but you can easily replace these by SPDataSource.

    Let me know if you have any questions!

    Read more...

  • Getting the Topmost Hierarchical Parent in T-SQL

    Introduction

    It is normal in databases to have hierarchical tables, that is, tables that are related with themselves, forming a parent-child relation. For example, consider this:

    image

    The parent_id column points to the parent record, which, in some cases, will not exist.

    So, imagine we have a number of records, such as:

       1: INSERT INTO dbo.list (id, parent_id) VALUES (1, NULL)
       2: INSERT INTO dbo.list (id, parent_id) VALUES (2, 1)
       3: INSERT INTO dbo.list (id, parent_id) VALUES (3, 2)
       4: INSERT INTO dbo.list (id, parent_id) VALUES (4, 3)

    How can we find the id of the topmost parent? In this case, it will always be 1, of course.

    In SQL Server, we have two options:

    1. A Common Table Expression (CTE);
    2. A recursive function.

    Let’s see how to implement each.

    Common Table Expression Approach

    We need to write a CTE that starts with some record and goes all the way up until it finds the parent. Let’s wrap it in a nice scalar function:

       1: CREATE FUNCTION dbo.GetTopmostParentCTE
       2: (
       3:     @id INT
       4: ) 
       5: RETURNS INT
       6: AS
       7:     BEGIN
       8:         DECLARE @parentId INT
       9:  
      10:         ;WITH cte AS 
      11:         (
      12:             SELECT a.id, a.parent_id
      13:             FROM dbo.list AS a 
      14:             WHERE a.id = @id
      15:             UNION ALL
      16:             SELECT b.id, b.parent_id 
      17:             FROM dbo.list AS b
      18:             INNER JOIN cte AS c
      19:             ON c.parent_id = b.id
      20:         )
      21:  
      22:         SELECT TOP 1 @parentId = id
      23:         FROM cte
      24:         WHERE parent_id IS NULL
      25:  
      26:         RETURN @parentid
      27:     END
      28: GO

    I won’t explain here how CTEs work, they have been around for quite some time, and there are several posts how there for that.

    Recursive Function Approach

    The other approach is using a recursive function. The gotcha here is that when we create a function, it is compiled, and if it has a reference to itself – which doesn’t exist first – it will fail. Therefore, we need to first create a dummy function and then change it to do what we want:

       1: CREATE FUNCTION dbo.GetTopmostParent
       2: (
       3:     @id INT
       4: )
       5: RETURNS INT
       6: AS
       7: BEGIN
       8:     RETURN
       9:     (
      10:         SELECT 0
      11:     )
      12: END
      13: GO
      14:  
      15: ALTER FUNCTION dbo.GetTopmostParent
      16: (
      17:     @id INT
      18: )
      19: RETURNS INT
      20: AS
      21: BEGIN
      22:     RETURN
      23:     (
      24:         SELECT CASE WHEN parent_id IS NULL THEN id ELSE dbo.GetTopmostParent(parent_id) END
      25:         FROM dbo.list
      26:         WHERE id = @id
      27:     )
      28: END
      29: GO

    Conclusion

    You can get results from the two functions by running the following T-SQL queries:

       1: SELECT dbo.GetTopmostParent(4)
       2: SELECT dbo.GetTopmostParentCTE(4)

    Interesting, both execution plans are exactly the same:

    image

    I can’t really recommend one over the other, since from my tests, both took the same amount of time (you will need far more records than the ones from my sample to tell that).

    So, any thoughts from database gurus out there?

    Read more...