Posts Tagged ‘SPList’

Check if User Has Permissions on List or WebSite

June 11th, 2010 3 comments

Recently I was working on a web part where I have to check for current user permissions for different lists in multiple sub-sites. I found a very straight forward method from SharePoint API. (DoesUserHavePermissions)

This method has some variations on site and list levels. 

On site level this method can take two parameters, string loginname and SPBasePermissions. You can use these parameters with two variations. If you don’t pass the login name then it verifies the permission level against the current user. SPBasePermissions is an enumeration. You can find more details about SPBasePermissions here.

On list level this method can again take two parameters, but three variations in method parameters. If you just pass the SPBasePermissions then it verifies the permission level against the current user. Then you can check permissions for a specific user and in third variation you can apply folder check. You can find more details on SPList.DoesUserHavePermissions here

You can use this method like this

if (oWeb.DoesUserHavePermissions(SPBasePermissions.ViewPages))
       SPList oList = oWeb.Lists[ListName];

        if (oList.DoesUserHavePermissions(SPBasePermissions.ViewListItems))
         // some smart code


SPList Bits and Pieces

August 19th, 2009 1 comment

Recently I have gone through a very informative white paper on Sharepoint SPList. I’m impressed with the deep knowledge of the author. I have this white paper with me and it’s a word document on 22 pages. I have summarized some important information from it. Hope you will enjoy it.

Maximum number of items in SPList

You might read on internet that SPList can contain maximum 2000 elements. First of all it’s definitely wrong. The maximum number of items supported in a list with recursive folders is 5 million items.
There is a limit of 2000 items, but it is for each container. You can think of container as a root folder for items. Without any folder in a list, list itself will be a container for items. So you can have 2000 items in a list without any folder. But if you create folders and sub folders then you can have millions of items in a list.
This limit is because of standard Sharepoint UI, if you have your own UI you can cross this limit of 2000 items.

Data access methods

There are eight different methods to access data from SPList. This figure is interested, I also had no idea about all the methods.

  • Browser
    The list was viewed using a browser and the predefined Office SharePoint Server 2007 interface.
  • SPList with For/Each
    This is we normally use by looping through SPListItemCollection of SPList.Items.
  • SPList with SPQuery
    The OM was used to create an SPQuery object that contained the query criteria. That object was then used to against an instance of the list in a SPList object. The results of the query were returned by calling the GetItems method on the SPList object.
    SPList.GetItems (SPQuery)
  • Browser
    In this case an instance of the list is obtained with an SPList object. The data from it is then retrieved into a DataTable by calling the GetDataTable() method on the Items property —for example, SPList.Items.GetDataTable(). The DataTable’s DefaultView has a property called RowFilter that was then set to find the items.
    SPListItemCollection.GetDataTable ()
  • SPListItems with DataTable
    This method is similar to the SPList with DataTable method, but with a twist. An instance of the list is retrieved through an SPList object. An SPQuery object is created to build a query, and that query is executed against the SPList object, which returns an SPListItems collection. The data from that collection is then retrieved into a DataTable by using the GetDataTable() method on the SPListItems collection.
  • Lists Web service
    The Lists Web service, which comes with Windows SharePoint Services 3.0 and Office SharePoint Server 2007, was used to retrieve the data. A Collaborative Application Markup Language (CAML) query was created and submitted along with the list identifier, and an XML result set was returned from the Lists Web service.
  • Search Object Model
    The search object model was used to execute a query against the Office SharePoint Server 2007 search engine and return the results as a ResultTableCollection. In order to use search for SPList, you need to create managed properties and perfrorm indexing on them.
  • PortalSiteMapProvider
    One approach to retrieving list data in Office SharePoint Server 2007 that’s not very well known is the use of the PortalSiteMapProvider class. It was originally created to help cache content for navigation. However, it also provides a nice automatic caching infrastructure for retrieving list data. The class includes a method called GetCachedListItemsByQuery. This method first retrieves data from a list based on a SPQuery object that is provided as a parameter to the method call. The method then looks in its cache to see if the items already exist. If they do, the method returns the cached results, and if not, it queries the list, stores the results in cache and returns them from the method call.
    This looks something very interesting to use.

Query data from large list

I have always find people in trouble when accessing large lists in Sharepoint. They always complaint that Sharepoint lists are very slow in accessing data. Actually it’s all about how you access data from SPList. We have just noticed that there are eight ways to access data from SPList. Now before using any of the option you have to see which one is more suitable in your system.

  • Methods shouldn’t use when accessing large lists
    • Browser View
    • SPList with For/Each
    • SPList with DataTable
  • Fastest methods to query large lists in WSS
    • SPList with SPQuery
    • Lists Web Service
    • SPListItems with DataTable
  • Fastest methods to query large lists in MOSS
    • PortalSiteMapProvider
    • Search API
    • SPListItems with DataTable (it seems even faster to search API, if the number of items in the list are not too much, say for 1500 items it’s a better option.)

Search performed well across all of the scenarios. One drawback to using Search is that it cannot retrieve data until indexing has completed, so if immediate data retrieval is a requirement, Search may not be the best choice. You might need to configure Managed properties.
The PortalSiteMapProvider class was one of the best performing data access methods in every scenario. However, there are a couple of limitations in using it. First, because of the way in which the data is cached, use of the PortalSiteMapProvider class is going to be most useful if the data you are retrieving is not significantly different over time. If you are trying to frequently retrieve different data sets, the PortalSiteMapProvider class will incur the overhead of constantly reading from the database, inserting data into the cache and then returning it from the method call. Clearly, the advantage of the PortalSiteMapProvider class is when it can read data directly from the cache.
Using the SPList class gives you several options to retrieve data — a For/Each enumeration, the Items collection, the GetDataTable method of an SPListItems collection, and using an SPQuery object to filter data. Some of those methods, specifically the GetListItems and GetDataTable from the results of GetListItems, routinely performed well in most scenarios. However, there are some limitations. For example, the GetListItems method won’t work across folders in a single list unless the ViewAttributes property of your SPQuery query class includes Scope=”Recursive”. For that matter, it won’t work across lists if you want to query data from multiple lists or subsites. It also requires that all code runs directly on the Office SharePoint Server 2007 computer. Other options, like the Lists Web service and the Search Web service can retrieve the data but run on remote servers.

Data maintenance considerations

There are a few other issues to consider when creating lists with more than 2,000 items per container. One is the cost of other common operations such as adding or deleting items from the list. Performance for deleting items degrades significantly when a list becomes very large. Deleting a single item from a very large list takes much more time than deleting an item from a smaller list.

Data locking

Another important consideration when using large lists is the concept of the locks that Microsoft SQL Server™ places on data tables that contain list information. Virtually all data for all Office SharePoint Server 2007 lists is contained within a single table in SQL Server. This table contains data for all the lists in all the site collections whose data is stored in that content database. When you attempt to update data on a list item, whether that is adding, editing or deleting a list item, SQL Server will attempt to lock other items (rows to SQL Server) for that particular list.
However, there is a limit to the number of individual rows that SQL Server will try to lock down. If you try to select approximately 5,000 items or more simultaneously for reading or update, SQL Server will typically lock the entire table for the duration of that change. In this event, all other reads and writes for all lists in all site collections are queued until the previous transaction is complete and the lock is released. If your query retrieves data across multiple folders within the list, the locking behavior occurs whether or not list items are recursively nested so that there are not more than 2,000 items in an individual container. To ensure that you don’t encounter this locking behavior, make sure the number of items you retrieve in a single request is well below this threshold. For example, you can control the number of records returned by setting the RowLimit on the SPQuery class.
Crawl times

Another consideration with very large lists is crawl time and crawl time-outs. As a list gets larger, the chances of the indexer timing out when crawling the contents of that list increases. If the indexer is timing out when crawling large lists, you can increase the time-out value with the following steps:

  1. In Central Administration, on the Application Management tab, in the Search section, click Manage search service.
  2. On the Manage Search Service page, in the Farm-Level Search Settings section, click Farm-level search settings.
  3. In the Timeout Settings section, in the Connection time and Request acknowledgement time boxes, enter the desired number of seconds.

I will try to add word file or post the URL of white paper for more information.

Have fun .

Categories: MOSS Tags: ,