abdrasin

Hopefully you do not have more than 100 groups in your site collection, but if you do you might notice that when you go to view them all they do not all display. 

Groups.aspx is showing a view of the User Information List.  The view is hidden (which means you probably shouldn't be messing with it) but if you want to you can by using /_layouts/ViewEdit.aspx.  You need to pass the Guid for both the list and view to this page, like this:

http://myWSS.com/_layouts/ViewEdit.aspx?List={00000000-0000-0000-0000-000000000000}&View={00000000-0000-0000-0000-000000000000} 

You can get the Guid for the User Information List using the GetListCollection web method on /_vti_bin/Lists.asmx.

You can get the Guid for the View by passing the Guid for the list to the GetViewCollection web method on /_vti_bin/Views.asmx

I get this occasionally when using Lists.asmx to query for list items.

 It is usually because in my Query I have a Value element that does not contain a Type attribute.

For example, to find items with no attachments:

<Query><Where><Eq><FieldRef Name="Attachments"/><Value>0</Value></Eq></Where></Query>

This will cause the error, to fix it:

<Query><Where><Eq><FieldRef Name="Attachments"/><Value Type="Attachments">0</Value></Eq></Where></Query>

I am posting this to remind myself, and because when I googled it I didn't get anywhere.

I had an elusive 403 error on a customized default.aspx that was using the Calendar Extender from the AjaxControlToolkit.

The error would only appear if the application pool had not yet fired up, and the user making the request was not an Administrator on the server receiving the request.

If an administrator requested the page it would load fine, and the normal user who just received the 403 could reload and get the page.  It seems that the only way the application pool would load the AjaxControlToolkit assembly is if it was an administrator making the request.

I was running the AjaxControlToolkit assembly from the bin.  It had CAS entries for unrestricted access, but that was not good enough.  The only solution to this problem was to place the AjaxControlToolkit in the GAC.

 Hope this saves someone else some time, because it took me half the morning to figure it out!

I recently spent time customizing a DataFormWebPart to show recent changes in our site.  The data source for this was linked across multiple lists and libraries.  When I was developing the web part I was working in the same Web as all of the lists and libraries in the data source.  My idea was that I would develop the web part in this location and then make it available for display anywhere within the site collection.  To my dismay, when I tried to add the web part to a page in a different Web than the one in which it was developed (and all the lists/libraries in the data source lived), it broke.

The problem was that my data source did not contain parameters for WebURL.  I found this out by recreating the web part in a different Web.  I noticed when I looked at my data source in code view that there was another parameter for each list or library: WebURL.  I recognized this parameter from the Lists web service's GetListItems as the place to specify the site relative url to the web in which the list lives if not in the web which you are running the query.

I went back to my original web part and added the WebURL to all the Lists/Libraries in my datasource, and of course it worked like a champ on whichever Web I imported it.

Here's the beginning of the data source before adding the WebURL parameter:

<SharePoint:SPDataSource runat="server" SelectCommand="&lt;View&gt;&lt;Query&gt;&lt;Where&gt;&lt;Gt&gt;&lt;FieldRef Name=&quot;Modified&quot;/&gt;&lt;Value Type=&quot;DateTime&quot;&gt;&lt;Today OffsetDays=&quot;-7&quot;/&gt;&lt;/Value&gt;&lt;/Gt&gt;&lt;/Where&gt;&lt;/Query&gt;&lt;/View&gt;" DataSourceMode="List" UseInternalName="True" InsertCommand="" DeleteCommand="" UpdateCommand="">
 <SelectParameters>
  <asp:Parameter DefaultValue="DD1EA27A-6BB9-440B-B21A-6D52F218F243" Name="ListID"></asp:Parameter>
 </SelectParameters>…

Here's what it looks like after adding the WebURL parameter (my list was at the root of the site collection, hence the '/' as the value)

<SharePoint:SPDataSource runat="server" SelectCommand="&lt;View&gt;&lt;Query&gt;&lt;Where&gt;&lt;Gt&gt;&lt;FieldRef Name=&quot;Modified&quot;/&gt;&lt;Value Type=&quot;DateTime&quot;&gt;&lt;Today OffsetDays=&quot;-7&quot;/&gt;&lt;/Value&gt;&lt;/Gt&gt;&lt;/Where&gt;&lt;/Query&gt;&lt;/View&gt;" DataSourceMode="List" UseInternalName="True" InsertCommand="" DeleteCommand="" UpdateCommand="">
 <SelectParameters>
  <asp:Parameter DefaultValue="DD1EA27A-6BB9-440B-B21A-6D52F218F243" Name="ListID"></asp:Parameter>
  <asp:Parameter DefaultValue="/" Name="WebURL"></asp:Parameter>
 </SelectParameters>

In short, if you plan on distributing a web part across webs that makes use of the SPDataSource, ensure that you include the WebURL parameter.

I have a DataFormWebPart that displays Documents/List Items from 4 or 5 libraries/lists that have been modified in the past 7 days.  I went to add the toolbar that allows for grouping, sorting, and filtering, not the simple one where you get to sort/filter in the column headers, but the big thick one that lets you group also. 

I noticed a problem right away in that when I clicked the Filter link I got 4 different Select controls for the Title field, and a Select for a field that I don't even have in my list of columns being displayed.  That was easy enough to fix-up via the Xsl.  Locate the dvt_1.toolbar template and toward the bottom of it you'll find an xsl:if test on the dvt_adhocmode variable.  The sections that follow determine which Selects you will see when you click the Filter link.  I just removed the ones I didn't want.

The next problem wasn't so simple (for me anyway).  One of the columns I chose to show in my data view was the ContentType.  I noticed that in the filter options for this column that there were many options that were showing up multiple times.  The list was ordered appropriately, there were just duplicate entries in it.  The filter options for all the other columns in my list was fine.  So I searched and searched and searched (ow!) and here's my hack to fix this.  Locate the dvt.filterfield template in the Xsl and locate the following xsl:for-each statement:

<xsl:for-each select="msxsl:node-set($dvt_Rows)/*[not(@*[name()=$dvt_FieldNameNoAtSign]=preceding-sibling::*[1]/@*[name()=$dvt_FieldNameNoAtSign])]/@*[name()=$dvt_FieldNameNoAtSign]">

All I did to fix it was remove the [1], like this: 

<xsl:for-each select="msxsl:node-set($dvt_Rows)/*[not(@*[name()=$dvt_FieldNameNoAtSign]=preceding-sibling::*/@*[name()=$dvt_FieldNameNoAtSign])]/@*[name()=$dvt_FieldNameNoAtSign]">

My guess is that for some reason the portion of the Xsl right before this line failed to sort properly the rows based on their ContentType attribute.

I've been working a lot recently with the DataView web part and ran into a problem today.  I tried to open my webpartpage that contains a DataViewWebPart in SharePoint Designer.  It opened, but SharePoint Designer ate a lot of processor and was responding very slowly.  I put my cursor in code view and tried to scroll and the Designer froze up.  After 15 minutes it still wasn't responding and I had to end it.  I tried again, rebooted, tried again, and finally decided to do some more investigation.  I requested the page from SharePoint in my browser and got the 'Unexpected Error…'.  I opened the Document Library in Explorer view and copied my page to local disk.  First thing I noticed: the page was 8.2MB.  ??? All it had was one DataView webpart (it was a test page).  I opened it in notepad, and guess what… notepad froze too.  Good thing I had version history turned on… I looked at the versions and noticed that the size of my page was doubling with each version.  ??? I opened one that was only 400KB in size and noticed the problem immediately.  In the middle of my Xsl for the DataView web part there were 1000's of blank lines.  The lines were composed of 3 tab characters each.  In the bigger files there were 3 or 4 sections of 20'000+ of these lines.  For whatever reason (I don't know if I want to know or not) SharePoint Designer was adding these lines to the dvt_1.toolbar template in my Xsl when I clicked the Save button.  Now, periodically between saves, I check the Xsl for these large chunks of whitespace and delete them.

Just a word of caution if you'll be saving your DataView web part repeatedly, don't let it get bloated.

I was trying to update a site column and kept receiving this error message. 

I had created this site column using the Webs web service's UpdateColumns method.  Actually, what I did was migrate site columns (a lot of them) from one site to another using the Webs web service.  Turns out that this caused a lot of odd problems, and I wouldn't recommend it unless you are extremely fastidious about the column definitions as you transfer them.  What I did was to take the results of GetColumns, iterate through the Field elements, take each element's InnerXml property and create a new Field element to pass to the UpdateColumns method on the other site. 

It turns out that what you get from GetColumns shouldn't necessarily be used to populate UpdateColumns.  For instance, the error above was caused by a Version="2" attribute on the column in question.  To determine the problem I created a new column using the standard ways through the interface and compared the definitions of the two.  The only difference was that pesky Version attribute.  Once I removed that from the original column's definition I could update it like any other column.

I was working on customizing the Display Form for a custom list using SharePoint Designer.  The first thing I did was remove the ListFormWebPart that is the default display for a list item.  I worked hard adding a custom display for the list item using Xsl styling and the DataFormWebPart.  Everything looked all good and I was able to see my changes… when I noticed that the links on AllItems.aspx no longer directed me to DispForm.aspx when I wanted to view a list item.  Instead I got directed nowhere, ie http://myserver/?ID=3.  I double checked the properties of my list in SPD by locating the list and right clicking it and choosing Properties.  Sure enough, on the Supporting Files tab the Display Item form: field was blank.  So I used the Browse… button to point it back to DispForm.aspx for my list.  I checked AllItems.aspx again and it still was displaying those broken links.

 No matter what I did I could not get those links fixed, even resetting DispForm.aspx to the site definition did not fix my problem.  I noticed curiously enough that when I reset the form to site definition I did not get a ListFormWebPart back, I got a DataFormWebPart in its place that looked and behaved the same.  This started me snooping around a bit and I found that if I got a ListFormWebPart back on DispForm.aspx, the links on AllItems.aspx were fixed up.  So that's my answer to this problem if anyone else has it.  You may not want the ListFormWebPart, if that's the case just change its IsVisible property to 'false', but from what I've seen you've got to have one on your DispForm for the list to recognize this is the default display form for list items.