After a day or so of development with this new tool the one thing that became immediately obvious to me was how limited the actual queries could be.  Perhaps it was because of the data model/relationships of the lists but the majority of the queries I needed to run could not be done with pure Linq since Linq to SharePoint can only run queries which span across no more than two lists which was a huge problem for me since many of my queries needed to span upwards of four lists. (I probably should have noticed that in the documentation).

Query limitations aside I was able to get my code working and decided to do some due diligence and fire up a load tester to see what kind of performance these web services would provide.  What I found was pretty shocking.

After reaching around six requests per second the CPU of the WFE (web front end) would become maxed out with page response times hitting nearly 2 seconds.  This seemed like a surprisingly low amount of performance since the server it was running on had four CPUs and four GB of ram (albeit it is a VM) so I decided to see where all of that CPU time was being spent so I hooked up the Visual Studio profiler and noticed that over 80% of the time was being spent in the inner workings of the Linq to SharePoint code.

At this point I decided to see what would happen if I replaced all of the Linq to SharePoint queries with plain old CAML queries running against the SPList.GetDataTable method.  The load tester was then run and came up with these numbers:

By using CAML queries the WFE was able to handle around 20 requests per second until its CPU maxed out, quite an improvement!

Then per my bosses request I created the same data model with a plain old relational database (SQL 2008r2) to see what the performance for the web service would be like with SQL as opposed to SharePoint.

As most people would suspect this preformed by far the best with the WFE being able to handle around 50 requests per second!

Although this may not have been the most scientific test in the world it definitely shows the overhead which Linq to SharePoint introduces as well as the overhead which SharePoint lists have over plain old SQL.  The lesson I’ve taken away from this is that Linq to SharePoint is okay for smaller/simpler projects where performance is not as important as getting the development done quickly however I will be staying away from it in the future.

The below example creates a cross list dvwp that displays all calendar items from across a site collection on a web page or site.  After the cross list dvwp is created, any new sub site with a calendar list will have its entries compiled in the cross list dvwp. 

Things to know prior to starting  

List Server Template 
You need to know the list server template number for the list type you will querying for this solution.  I.e. A calendar list’s server template number is 106.  Each list type in SharePoint has a number associated with it and this number is required to create a cross list query.   For a listing of list types and their corresponding numbers,  visit this MSDN page: http://msdn.microsoft.com/en-us/library/dd340479(v=prot.13).aspx

Static/Internal Name versus Display Name for Columns
Most often columns have two names; an internal name and a display name.  I.e. In a calendar list the Start Time column has an internal name of EventDate.  When creating a cross list query the internal names are required.  For more information on internal vs. display names, read this blog by Marc Anderson:  http://sympmarc.com/2009/12/11/staticname-versus-displayname-on-sharepoint-lists/ 

Keep in Mind

There are pros and cons associated with using a cross list dvwp rather than purchasing a more robust 3rd party tool. 

 Create a cross list query       

 1.  In the browser, add a list view web part to a web part page or a site page. 
 

 2.  Format the view – include all columns and in the order they should appear in the final product.

 3.  Open SharePoint Designer.  Navigate to the web page or site where the list web part was added and view in Split mode.

4.  Convert the list view web part to a data view web part.  Right-click on the list view web part and choose Convert to XSLT Data View.

 5.  The dvwp needs to know where to query.  From the tool bar, choose Edit, then Find.

a.    Search for <ParameterBindings> 

After the open <ParameterBindings> tag, add the following parameter binding to the list using your site/sub site information (NOTE:  your site information may be /site/, or /site/subsite/, or, /site/sub site/sub sub site/, etc.): 

<parameterbinding Name=”WebURL” Location=”None” DefaultValue=”/site/subsite/“/> 

b.  Search for <xsl:param 

Above the first entry, add the following using your site/sub site information: 

<xsl:param name=”WebURL”>/site/subsite/</xsl:param> 

6.   This section tells the query what columns to match and display.

a.  Search for <DataSources>

b.  In the code pane in Designer, between the open <DataSources> and closing </DataSources> tags, look for the id=”[id_name_here]“.  Copy the existing id name and save it somewhere.  You will need this information in step 6d.

c.  In the code pane, delete the following code:  open <DataSources> tag to the closing </DeleteParameters> tag and all code between. This should leave you with the open <SelectParameters> tag to the closing </DataSources> tag. 

d. Above the open <SelectParameters> tag copy and paste the below open <DataSources> tag and following code and modify the items highlighted in yellow to match your list needs.

<DataSources><SharePoint:SPDataSource runat=”server” DataSourceMode=”CrossList” SelectCommand=”<View><Webs Scope=’Recursive’></Webs><Lists ServerTemplate=’106‘></Lists><ViewFields><FieldRef Name=’FileDirRef‘/><FieldRef Name=’ID‘/><FieldRef Name=’Location‘/><FieldRef Name=’Title‘/><FieldRef Name=’EventDate‘/><FieldRef Name=’EndDate‘/><ProjectProperty Name=’Title‘/></ViewFields><Query></Query></View>” UseInternalName=”True” id=”datasource2“>

CODE OVERVIEW  

Highlighted text – readers of this blog should replace highlighted text with values that correspond to their solution.  
***I.e. If your cross list is NOT querying calendar lists, then the list server template of 106 should be replaced with the correct value.
***The <FieldRef Name> tags tell the data view what columns to display.  If a column should appear in the dvwp, be sorted on, or filtered on, the column name MUST have a <FieldRef Name> tag.  NOTE:  You can have as many or few <FieldRef Name> tags as necessary.  

Text in red should not be deleted. 
***The Cross added in the DataSourceMode is the key to searching across the site collection for items of the same list server type. 
***The FileDirRef reference identifies information about the file directory.  Do no delete this FieldRef.
***The ProjectProperty Name=”Title/” reference populates the site name the list item is popultating from.  Do not delete this reference if you want to note what site the item in your query is pulling from. 

Click anywhere in the design pane of Designer.  The dvwp should now contain  items from across the site collection that are saved to lists using the list server template you defined in step 6d.
   

7.  The Title field does not link to item display forms.  To enable this functionality, search for select=”@Title” and locate the reference inside of a <xsl:value-of  tag.

a.  The xsl:value-of tag that contains the @Title will reside inside of an <a> tag – delete the open <a> and closing </a> tags and all code inside of it. 

b.  Replace the text with the following: 

<a><xsl:attribute name=”href”>/<xsl:value-of select=”substring-after(@FileDirRef,’;#’)” />/Dispform.aspx?ID=<xsl:value-of select=”@ID” /></xsl:attribute><xsl:value-of select=”@Title” /></a>

8.  To add the site name where each item resides, Right-click the dvwp and choose Show Common Control Tasks, choose Edit Columns, then select ProjectProperty.Title and hit the Add button to display that column in the dvwp.  After the column is added, in the code pane, edit the column header to read as Site. 

 NOTE: My example does not contain any name columns, but if it did…  Columns that display names will contain extra characters (D’oh!).  To correct this, edit the xsl command containing the column name (thanks to Lee Kohnn for helping me with this one).  Columns that display names include but are not limited to: AssignedTo, Requestor, Author, Editor. 

Search for select=”@[Column Internal Name]” and locate the reference inside of a <xsl:value-of tag. 

a.  Replace the existing xsl with the following: 

<xsl:value-of select=”substring-after(@[Column Internal Name],’;#’)” /> 

The finished product

Voila, my cross list dvwp!  As new sub sites are added, any calendar list that contains items will automatically populate in my dvwp.  As items and/or sub sites are deleted, my dvwp will automatically update by removing those items.

Links

Here are some useful blogs I read to help unravel this solution for myself:

• http://platinumdogs.wordpress.com/2009/07/21/querying-document-libraries-or-pulling-teeth-with-caml/
• http://sympmarc.com/2009/04/21/displaying-columns-in-a-crosslist-dvwp/
• http://www.manliane.com/kb/157/

Figure 1 displays a screenshot my configured Birthdays list which displays only current month birthday entries on the home page of my site.  To create your own list that filters by current month follow the below steps. 

Getting Started – List Configuration (These steps are completed in the browser.)

1. Create a custom list and name it Birthdays.

2. Create the following columns:

Column 1)  Birthday (birthday)  /  Date and Time  /  Field is Optional

Column 2)  Birthday Month (birthdaymonth) / Calculated Column / Field is Hidden

=CHOOSE(MONTH(Birthday),”January”,”February”,”March”,”April”,”May”,”June”,”July”,”August”,”September”,
“October”,”November”,”December”)

Column 3)  Day (day) / Calculated Column / Field is Hidden

=”"&DAY(Birthday)

Column 4)  Employee (Title) / Single line of text / Field is Optional

Column 5)  Month (month) / Calculated Column / Field is Hidden

=CHOOSE(MONTH(Birthday),”01″,”02″,”03″,”04″,”05″,”06″,”07″,”08″,”09″,”10″,”11″,”12″)

Your column settings should display as in Figure 2 so that users do not see the hidden fields when a new birthday item is created.

3.  Create a view in the Birthdays list and name it currentbirthdays.  Columns to display are:
1- Birthday Month, 2- Day (ascending), and 3- Month (ascending).

Birthday list content and configuration 

Before proceeding to the Final Stretch section ensure your list contains the following:

Final Stretch – XSLT filtering in SharePoint Designer 2007

An XSLT filter is used to display only current month birthdays.  The XSLT expression uses the hidden Month column to compare the Birthday Month column to [Today’s] month.

NOTE: In SharePoint 2007 a list must be converted to a data view web part, while in SharePoint 2010 all lists are data view web parts. Due to this difference, the below screenshots taken from 2007 will differ from 2010; the general process for creating XSLT filters is the same.

4.  Open SharePoint Designer.  Navigate to the Birthdays list and double-click the currentbirthdays.aspx page to open it.

5.  Right-click and convert the list to an XSLT Data View.

6.  Right-click the data view web part and choose Show Common Control Tasks.

7.  Choose Filter.

8.  Check the Add the XSLT Filtering option and choose Edit.  The Advanced Condition dialogue box opens.

9.  In the Edit the XPath Expression field input the following XSLT and then click OK:
[@Month=number(ddwrt:FormatDateTime(string(ddwrt:Today()),1033,'MM'))]

10.  Select Ok to close the Advanced Condition dialogue box.

11.  Close Designer.  If prompted to Save or Check-in, do so.

NOTE:  After adding the list as a web part to a page or site, it may be necessary to repeat steps 4 – 11.

This post will be helpful to you if you have created custom SharePoint 2007 solutions using the VSeWSS Visual Studio extensions. The tool above can be used to easily upgrade these projects to SharePoint 2010 projects. This post should be especially useful if you are upgrading existing SharePoint 2007 sites to SharePoint 2010 that already have these Web Parts added and you would like the ability to add additional modifications to these projects.

Installing the VSeWSS Import Tool

The VSeWSS tool is actually provided as a Visual Studio Project, which needs to be compiled in order to build the executable to install the tool into Visual Studio. One other thing to note is that in order to open the solution in Visual Studio 2010, you need to install the Visual Studio 2010 SDK (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=47305cf4-2bea-43c0-91cd-1b853602dcc5&displaylang=en). Why this isn’t included in Visual Studio by default is beyond me. Or why it is not mentioned in the VSeWSS Import Tool installation instructions is also beyond me.

So basically, install the SDK, and then follow the instructions to install the new project type.

Importing Your Projects

To get started you want to copy any old Visual Studio project directories over to computer where you will be writing your Visual Studio 2010 solutions.

Once you have your old projects ready and have everything installed go ahead and fire up Visual Studio 2010. Click New Project and you will now have a new project template called Import VSeVSS Project (if the installation went well). See below:

Next, name your new projects exactly like they are in the old solutions in order to ensure your solutions upgrade correctly. Once you have named the project click the “OK” button. You should see the import dialog like this:

In the dialog, set a debug URL if needed, and change the trust level to full-trust. Next, click the “Browse” button and browse to one of your old projects. Select the “Project configuration” file and click “Open“. Finally, click “Finish“.

The tool will then go through and upgrade the files to reflect the new layout of a SharePoint 2010 Visual Studio solution. Once the upgrade is complete, if there were no errors, you should see the new project laid out in the Solution Explorer. If you have not created any SharePoint 2010 solutions you will notice that the solutions are organized in a much more intuitive fashion (in my opinion at least). If you are upgrading something that deploys as a feature (like a Web Part) you will notice a Feature folder as well as the Package folder. Your solution explorer should look something like this:

So that officially upgrades your solution! Technically you should be able to just run the deployment inside Visual Studio and deploy your solution as is, however I have found this to not always be the case.

Final Updates and Fixes

Below you will find a list of items that I make it a habit of checking before I consider the project officially upgraded. You may or may not need to make these changes. Hopefully these will save you some time as I spent about a week figuring most of these out on my own.

1. Update Feature Title, Description, and Scope – for some reason when I upgraded some of my Web Parts the feature title and description did not get carried over. To update these expand the Features folder and double click on the item(s) within. Then just fill in the boxes. Also, my Scope was changed to Web for many of my features that were originally set to Site. Just change that in the drop down.
2. Update the Deployment Path (this one is just me being a little bit retentive) – By default the feature will be deployed to the Feature directory in the form of <NAMESPACE_FEATURE>. For me the feature part was unnecessary so to remove this, while updating the section above you will see a property called Deployment Path in the Properties window. In this property you will see something like $SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$. You want to remove $_$SharePoint.Feature.FileNameWithoutExtension$.
3. Add SafeControl entry to spdata file (if your project is a Web Part you may need to make this change) – The spdata file specifies the contents and behavior of a SharePoint project item. In order to see this file, click the “Show All Files” button at the top of the Solution Explorer. You should see the spdata file within your individual project directory. In the file paste the following below the Files element (replace the placeholders):
   

   <SafeControls>

   <SafeControl Name=”SafeControlEntry1” Assembly=”$SharePoint.Project.AssemblyFullName$” Namespace=”<NAMESPACE>”

   TypeName=”<TYPENAME>” IsSafe=”True” IsSafeAgainstScript=”False” />

   </SafeControls>

4. Update Elements.xml – My elements.xml (actually not named elements.xml in my case) file is actually the file which caused me the most grief. For things like Web Parts, this file is what is used to specify what happens when the feature is enabled. For some reason when I would try to add a Web Part after enabling the feature I would get the following error:

It turned out that the Web Part was actually being added to a folder within the Web Part catalog, which is why the error notes a directory. I’m not sure if this has something to do with differences in SharePoint 2007/SharePoint 2010 Web Parts or if it was an issue in the upgrade, but either way it needed to be fixed for every one of my Web Parts that are added as features.

To fix this issue, remove the directory part of the URL in the Url property of the Elements.xml file. More specifically within the File xml element you will see a Path and a Url. If within the Url you see something like <DIRECTORY\example.webpart>, remove “Directory\.” This one drove me crazy because when I enabled the feature a file was getting added to the Web Part Gallery, but it wasn’t an XML file. It actually came down to me writing a PowerShell script to determine what exactly the file was.

Two more things that are probably just for good measure are to add “Type=GhostableInLibrary” to the File element and to specify a value for a group. Here is what mine looked like after everything was updated:

<?xml version=”1.0” encoding=”utf-8”?>

<Elements Id=”<ID>” xmlns=”http://schema.microsoft.com/sharepoint/”>

<Module Name=”Test” List=”113” Url=”_catalogs/wp”>

<File Path=”Test\Test.webpart” Url=”Test.webpart” Type=”GhostableInLibrary”>

<Property Name=”Group” Value=”Custom” />

</File>

< /Module>

</Elements>

I hope this post is informative and time saving for you and I hope it will allow people to deploy much cleaner solutions to their brand new SharePoint 2010 environment. As always, please leave a comment if you have any questions, additional tips on this topic, or if you have a better solution to share. Thanks!

But did you know that there are many Site Columns that can’t be removed from Site or List Content Types?

Below is a list of Site Columns confirmed to be persistent on Site & List Content Types in SharePoint 2010.

Get-SPScripts provides some very helpful Powershell scripts to remove such columns if necessary.

It appears that Site Content Types that using or having used one or more “persistent Site Columns” cannot be deleted.  A custom Site Content Type (named “Service”) was used to test behavior of these persistent Site Columns.  It could not be deleted through the SharePoint web UI due to an error stating: “The content type is in use.”

To confirm Site Content Type usage, each List and Site Content Type was inspected; no objects were found to use the “Service” Site Content Type.  Using SharePoint Manager 2010, it was confirmed that the Site Content Type was not being used.

Unfortunately, the “Service” Site Content Type could not be deleted using SharePoint Manager 2010 due to an error stating: “Exception has been thrown by the target of an invocation.”  Under the suspicion that the persistent Site Columns were causing unanticipated behavior, they were removed from the “Service” Site Content Type using Get-SPScripts’ PowerShell scripts through the SharePoint 2010 Management Shell.  Unfortunately, the “Service” Site Content Type still could not be deleted using the SharePoint web UI, SharePoint Manager 2010, or PowerShell scripts.

If you answered “yes” to each of the above questions, switch your query string variable name from “ID” to something -anything- else.

SharePoint 2010 apparently reserves “ID” for peculiar usage and therefore cannot be used as freely as with SharePoint 2007.

What does this mean?? It means translation is necessary.

Here’s an incomplete Rosetta Stone:

For all of you out there that have not yet been allowed the opportunity to dig into the vastness that is SharePoint 2010 and have become bored with SharePoint 2007, I just might have something new for you to play with. That’s right…PowerShell! My new addiction…

Note that before getting started, you should have a good working knowledge of the SharePoint Object Model.

Step 1: Get started

PowerShell by default comes with Windows Server 2008, however it doesn’t come with Windows Server 2003 and my guess is that if you’re still running SharePoint 2007 you’re probably still running Server 2003. If you are among this group, all you need to do is install the hotfix (KB926139) on one of your web servers. If you’re running Server 2008, you’re ready to go.

Step 2: Get excited!

So without getting too deeply into the nuts and bolts of PowerShell, what you need to know is that it gives you a command line interface, which provides the added ability of leveraging compiled code without actually compiling any of your own code. How could anyone not be excited about that?

And given the richness of the SharePoint object model, you are basically given unlimited potential for managing your SharePoint applications.

Step 3: Get to Work

Go ahead and fire up PowerShell. Also start up your favorite text editor program because we will write a few simple scripts. In these scripts we will do a few things: specify command line arguments, load any required libraries, and write some code to run the program.

Within your text editor paste the following:

param([string] $url)

[System.Reflection.Assembly]::Load('Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c') | Out-Null

$site = new-object Microsoft.SharePoint.SPSite($url)
$site
$site.Dispose()

If you look at the above code you will notice the 3 things I mentioned earlier. The param section which specifies that we will accept a parameter named “url” which is of type string. The next section specifies which assemblies should be loaded. We are loading in the “Microsoft.SharePoint” assembly, which is generally all you will need for these kinds of scripts. Also note in this section the “| Out-Null” command. This just basically suppresses PowerShell from outputting whether or not the assembly was successfully loaded. Finally, the last section is where we are running our code. We are just creating an SPSite object from the passed in URL, displaying the contents of the SPSite object, and finally disposing of it (never forget to dispose of objects when needed).

Now go back to your PowerShell window and type the following (replace <SITE URL> with the URL of your SharePoint site) and hit enter:

If the command runs correctly your output should look like the following screenshot (Click image to enlarge; if you receive an error stating something about an execution policy see this link http://technet.microsoft.com/en-us/library/ee176961.aspx):

What you are seeing are all of the properties, methods, objects, etc of the $site (SPSite) object. You can actually do this with any objects that you create in PowerShell. By just entering $site on its own line, you are telling PowerShell to output the contents of that object. This is usually where I start when I write scripts so that I can find all of the elements that I need.

So to recap, what we did was wrote a script that: 1) accepts a URL parameter; 2) loads the SharePoint library; 3) creates an SPSite object based on the passed in URL; 4) displays its contents; and finally 5) disposes of it. Very simple right?

Step 4: Get Something Useful

I don’t know about you, but on numerous occasions I’ve been asked to provide a list of all inactive sites in my environment. Now you can do things like set policies to delete sites that are inactive automatically, but sometimes that isn’t the best way to go about it. So if you’re in that boat, how do you get this information? You could always write a SQL script to query the databases, but why do that if you don’t need to? How about we make use of the SharePoint Usage data?

So for this example, our script will provide us with a list of all top-level sites in a specified web application that have not been accessed within the past month. Additionally this script will provide us with the ability to specify users to not count, as well as provide the ability to export to CSV. Open up a new text editor window and paste the following:

param($url, [string[]] $users, [switch]$exportToCSV)
[System.Reflection.Assembly]::Load('Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c') | Out-Null

# Lookup Web Application as specified in the command line parameter
$wa = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup($url) 

# Create an array to store a list of all inactive sites
$sites =@()

Write-Output("`nProcessing sites...`n")

# Loop through all site collections in the web application
foreach($site in $wa.Sites)
{
	$siteCount = $wa.sites.Count	
	# Counter used to track number of active users
	$counter = 0

	# Create a DataTable, which contains the user usage data for the past month
	$usage = $site.RootWeb.GetUsageData([Microsoft.SharePoint.Administration.SPUsageReportType]::user, [Microsoft.SharePoint.Administration.SPUsagePeriodType]::lastMonth)

	# Loop through all rows in the DataTable
	foreach ($row in $usage.Rows)
	{
# If the array of users to not count does not contain the current user, the user is unique, which means that the site is active, so increase the counter
		if ($users -notcontains $row.User)
		{
			$counter++
		}            
	}

	# If the counter is equal to zero, then no unique users were found, and the site is considered inactive
	if ($counter -eq 0)
	{
		# Create a generic object containing the site information and add it to the array
		$o = new-object psobject
		$o | Add-Member -MemberType noteproperty -Name Name -value $site.RootWeb.Title
		$o | Add-Member -MemberType noteproperty -Name Url -value $site.RootWeb.Url
		$sites += $o
 
		# Outputs any inactive sites that are found
		Write-Output("Site Processed: {0} (Inactive)" -f $site.RootWeb.Title)
	}

	else
	{
		# Outputs any active sites that are found
		Write-Output("Site Processed: {0} (Active)" -f $site.RootWeb.Title)
	}

	# Dispose of the SPSite object
	$site.Dispose()
}

# If the exportToCSV switch is entered, output the array of sites to CSV (without file type information)
if ($exportToCSV)
{
	$sites | export-csv "Inactive_Sites.csv" -noTypeInformation
}

# else output the array of sites to the screen in a formatted list
else
{
	$sites | format-list
}

#Output stats
Write-Output("`nTotal Sites Processed: {0}" -f $siteCount)
Write-Output("Total Inactive Sites: {0}" -f $sites.Count)
Write-Output("Processing complete`n")

Save this file as Get-InactiveSites.ps1

Now go back to your PowerShell window and type the following (replace <SITE URL> with the URL of your SharePoint site) and hit enter:

./Get-InactiveSites -url <SITE URL> -exportToCSV

If the command runs correctly your output should look like the following screenshot (Click image to enlarge):

Hopefully the comments explain everything that is going on here. And just be aware that this does cycle all site collections in your web application, so if you have a huge number of site collections, it may take a while to run. The only real thing to note is the –exportToCSV switch, which instead of outputting the results to the screen, they are outputted to a CSV. Awesome!

Let me know if you have any questions or comments below in the comments section.

If you ever have had the need to create your own pagination for SharePoint 2010 lists/views you will undoubtedly have run into a class called SPListItemCollectionPosition which is supposed to handle going forwards and backwards in the paging.  Unfortunately as of this post the documentation on this little gem is non-existent.  So after doing some googling and experimentation here are some things I have learned which can hopefully save some of you some time trying to figure this stuff out.

• All of the data this class encapsulates is really stored in a string with various parameters encoded like a query string
• The parameters which you need to concerned with are:
  • Paged=True This parameter tells SharePoint that you’re trying to paginate the data
  • p_ID Is used in two different ways
    • When paging forward this should equal the ID of the last item on the current page
    • When paging backward this should equal the ID of the first item on the page
  • PagedPrev should be se to TRUE when paging backwards
    • Can be omitted when paging forwards
  • p_[ColumnName] When using sorting this functions in the same way the p_ID field works except the value should come from the column being sorted on, not the ID of the item.
    • [ColumnName] is replaced with the name of the column being sorted on
    • EX) If your sorting on the Title column the parameter should be called p_Title
      • If paging forward it should be set equal to the Title value of the last item on the page
      • If paging backward it should be set equal to the Title of the first item on the page
  • PageLastRow is used when paging backwards.  It should be set to the index of the last item on the current page
  • PageFirstRow is used when paging forwards.  It should be set to the ID the first item on the current page

If you’re looking for more information on how this works one good place to look is in the query string for the out of the box list views.  As you sort and page through the data you’ll see these parameters in the query string of the page which provides a nice place to do some experimentation.  Also please note a few gotchas which I encountered while working with this:

• If sorting is being done on a DateTime column then the value for the p_[ColumnName] attribute needs to be in UTC not local time
• The API only allows for going from the current page to the next or previous page.  You can’t jump arbitrarily between pages
• If filtering is being done on the view then there is no real ‘good’ way to determine if you are at the beginning or end of the pagination.  This is something you’ll have to figure out how to handle on your own

For more information take a look at the following links which helped me out a lot:

• http://charliedigital.com/2010/02/05/paging-with-splistitemcollectionposition/
• http://blogs.msdn.com/b/colbyafrica/archive/2009/02/19/learning-sharepoint-part-vi-list-pagination.aspx

When I started working here at MetroStar Systems, approximately 8 months ago, one of the very first things I remember being told was, “No Idea is a bad idea”…and I have learned that mantra definitely holds true.  It’s great to be in an environment where no matter how off the wall your idea may be, it’s always taken into consideration, provided feedback and sometimes given the green light to make it happen.  While most of the daily work hours are spent getting things done for clients, many of our developers and engineers spend their after-hours coming up with tools and solutions to help enhance and improve internal processes. As all these great ideas floated around, it was only a matter of time, something was created to house them…thus, StarLabs was born.

StarLabs is where our engineers and artists collaborate and share innovative projects. It allows those unfamiliar with MetroStar Systems to learn more about the behind the scene things we do and the people who bring them to life.

One of the current projects we feature on StarLabs is Visualize It, which provides a rich user experience for navigating and exploring SharePoint Libraries. It is a powerful solution for not only finding data but also discovering data. An example of how Visualize It works can be found on this blog! See the top of the page, the little guy holding the “Visual Search” banner. Click on it and type in a keyword like “SharePoint” and watch Visualize It in action.

Currently, Visualize It, is available for free download. System administrators can download it and implement it to their SharePoint Portals. If you test it out, please let us know your feedback!

Learn more about StarLabs and the different projects we are working on by visiting http://labs.metrostarsystems.com