The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.
Here’s an excerpt:
The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 32,000 times in 2014. If it were a concert at Sydney Opera House, it would take about 12 sold-out performances for that many people to see it.
This error can occur when using the KeywordQuery class and the QueryText property’s length is close to its limit (MaxKeywordQueryTextLength ) (but still below it)
Workaround is to shorten the QueryText. If that’s not an option, SearchExecutor.ExecuteQueries can be used to execute more queries parallel
Apparently Internet Explorer 10 is not compatible with Outlook Web Access 2003, but you can change the browser mode in IE to be able to use the PWA.
Press F12 in the browser to open the developer tools and in the “Browser Mode: IE10” menu select “Internet Explorer 9”. This will make the OWA believe that it is viewed via IE9 and it will work, at least our first smoke test passed.
This is the error that appears when you try to view your mails in the inbox via OWA :
/exchweb/img/tf_TwoLine.xsltable-layout:fixed;width:100%;Two-Line ViewBKBMBfalseNonepercentItem Typestringhttp://schemas.microsoft.com/exchange/outlookmessageclass1101width:20px;cursor:hand;text-align: center;Fromstringhttp://schemas.microsoft.com/mapi/sent_representing_name1001width:26%;cursor:hand;text-align: ;padding-right:3px;padding-left:3px;Receiveddateurn:schemas:httpmail:datereceived1001width:29%;cursor:hand;text-align: ;padding-right:3px;padding-left:3px;ddd M/d/yyyyH:mmFlagStatusi4http://schemas.microsoft.com/mapi/proptag/x109000031101width:20px;cursor:hand;text-align: center;Subjectstringhttp://schemas.microsoft.com/mapi/subject1001width:44%;cursor:hand;text-align: ;padding-right:3px;padding-left:3px;Importancei4http://schemas.microsoft.com/exchange/x-priority-long1101width:13px;cursor:hand;text-align: center;Attachmentbooleanurn:schemas:httpmail:hasattachment1101width:15px;cursor:hand;text-align: center;”http://schemas.microsoft.com/mapi/proptag/0x67aa000b” = false AND “DAV:isfolder” = falseurn:schemas:httpmail:datereceivedDESCdatebackground-color:buttonface
When opening the Project Web Access site of Project Server 2007 using Internet Explorer 10, you receive the following error:
At least Internet Explorer version 6 is needed to use Project Web Access.
Apparently IE10 is not compatible with PWA 2007, but you can change the browser mode in IE to be able to use the PWA.
Press F12 in the browser to open the developer tools and in the “Browser Mode: IE10” menu select “Internet Explorer 9”. This will make the PWA believe that it is viewed via IE9 and it will work, at least our first smoke test passed.
Error details:
Server Error in ‘/’ Application.
——————————————————————————–At least Internet Explorer version 6 is needed to use Project Web Access.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Microsoft.SharePoint.SPException: At least Internet Explorer version 6 is needed to use Project Web Access.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.Stack Trace:
[SPException: At least Internet Explorer version 6 is needed to use Project Web Access.]
Microsoft.Office.Project.PWA.PJBaseWebPartPage.OnPreInit(EventArgs e) +226
System.Web.UI.Page.PerformPreInit() +42
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1256——————————————————————————–
Version Information: Microsoft .NET Framework Version:2.0.50727.4984; ASP.NET Version:2.0.50727.4971
Problem
When changing the Site Template of a site the following error is shown in the browser:
A theme with the name “templatename 1011” and version already exists on the server.
at Microsoft.SharePoint.Library.SPRequestInternalClass.ApplyTheme(String bstrUrl, String pVal)
at Microsoft.SharePoint.Library.SPRequest.ApplyTheme(String bstrUrl, String pVal)Troubleshoot issues with Windows SharePoint Services.
Solution
- Open the site in SharePoint Designer
- Delete the _themes folder
- Perform an iisreset
- Try again, and it just works
This tip comes from here. Thanks!
Problem
A Project Manager is working with an .mpp projectplan localy, then he decides to save it to Project Server.
He saves the file to Project Server and Publishes the project. Then he notices that the values in some of the fields are replaced with “#ERROR”.
Investigation
The investigation shows that the affected fields are all Formula fields.
The mpp file got corrupted some way (probably by the project server). After saving the .mpp as .xml in Project Professional, we can see that an “Ltuid” attribute is appended to many formula columns in the file. This attribute should appear only for lookup columns. This attribute stores “The GUID of the lookup table associated with the custom field.” (MSDN) but in the corrupted file it stores an unknown GUID.
When checking the fields in Project Professional (Tools / Customize / Fields…) in the Custom Fields window the Custom Attribute of the affected fields is set to “Lookup…”, instead of “Formula…”
Workaround
We were able to temporarily fix the project plan changing the type of the fields back to “Formula…” from “Lookup…” in MS Project. Interestingly the formula itself was not lost, only the field type was corrupted.
Solution
Project Server 2007 SP3 solves this issue.
We had a standard SharePoint list where
• grouping was used in the list view
• at least one group contained more than 100 listitems
The user
• expanded the group with 100 listitems and clicked on the “more…” link to see the next page of the group.
• then chose “New item” from the menu to add a new listitem.
• Filled in the new form, and clicked OK
then received the following error:
System.Runtime.InteropServices.COMException: Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
[COMException (0x80020009): Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))]
Microsoft.SharePoint.Library.SPRequestInternalClass.RenderViewAsHtml(String bstrUrl, String bstrListName, String bstrViewID, String bstrViewXml, String bstrQualifier, ISPDataCallback pDataCallback, Boolean& pbSharedList) +0
Microsoft.SharePoint.Library.SPRequest.RenderViewAsHtml(String bstrUrl, String bstrListName, String bstrViewID, String bstrViewXml, String bstrQualifier, ISPDataCallback pDataCallback, Boolean& pbSharedList) +255[SPException: Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))]
Microsoft.SharePoint.Library.SPRequest.RenderViewAsHtml(String bstrUrl, String bstrListName, String bstrViewID, String bstrViewXml, String bstrQualifier, ISPDataCallback pDataCallback, Boolean& pbSharedList) +363
Microsoft.SharePoint.WebPartPages.ListViewWebPart.RenderView() +2129
Microsoft.SharePoint.WebPartPages.ListViewWebPart.EnsureData(Int32 token) +1368
Microsoft.SharePoint.WebPartPages.SharePointDataProvider.Execute() +343
Microsoft.SharePoint.WebPartPages.SPWebPartManager.ActivateV2ConnectionsAndSharePointDataFetch() +270
Microsoft.SharePoint.WebPartPages.SPWebPartManager.ActivateConnections() +137
System.Web.UI.WebControls.WebParts.WebPartManager.OnPageLoadComplete(Object sender, EventArgs e) +70
System.EventHandler.Invoke(Object sender, EventArgs e) +0
System.Web.UI.Page.OnLoadComplete(EventArgs e) +11042078
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3160
We had a HttpModule running on the IIS that did some URL transformations but it was not supposed to change the standard SharePoint URLs. After some troubleshooting we realized that the URL were changed by the HttpModule – they were UrlDecoded without any particular reason.
Original (good) URL:
New (bad) URL:
As you can see, the problem is in the Source parameter, which is an url itself, with its own querystring parameters.
Then we started to analyze the HttpModule to find out how the URLs got UrlDecoded. It did not contain any call to HttpUtility.UrlDecode or HttpServerUtility.UrlDecode nor any custom logic to do the decoding so we suspected that they were decoded as a sideeffect of something.
And that was the right assumption. We had to realize that some .NET methods UrlDecoded the URLs in a background. See the list of the methods and the solutions in this article.
We had an issue that some urls got UrlDecoded automatically without any apparent reason. We had to find out that some .NET methods implicitly UrlDecode the URLs even if you don’t want that.
The following methods surely decode the URLs, but there might be more:
HttpUtility.ParseQueryString(querystring)
This method returns a NameValueCollection that contains the QueryString parameters UrlDecoded.
If you want to use this method but don’t want the parameters to be decoded, you can use your own parsing algorithm. You can find one here:
http://stackoverflow.com/questions/68624/how-to-parse-a-query-string-into-a-namevaluecollection-in-net
Uri.ToString
You may expect that the result of new Uri(“url”).ToString() will equal to “url” but that is often not the case
The MSDN documentation and the sample code
also describe that the result of Uri.ToString is not the same as the original string. If you need the original, use the OriginalString property.
Uri uriAddress = new Uri("HTTP://www.Contoso.com:80/thick%20and%20thin.ht");
// The following outputs "http ://www.contoso.com/thick and thin.htm".
Console.WriteLine(uriAddress.ToString());
Probably you should not use this method in your code, unless you are logging or debugging. Use the OriginalString or AbsoluteUri properties instead.
When you try to change the Title of an SPList programmatically, you may see that your code executes without error but the Title of the list is not changed. I faced this problem when I was trying to change the Title from a console application where the SPContext did not exists.
I found the solution in this blog: http://www.sharepointblues.com/2011/11/14/splist-title-property-spfield-displayname-property-not-updating/
It turned out, that the CurrentUICulture of the SPWeb where your list is located MUST be the SAME as the CurrentUICulture of the thread where from you are updating the Title.
So now I use the following code to update a List’s Title:
private void UpdateListTitle(SPList list, string title)
{
CultureInfo ci = Thread.CurrentThread.CurrentUICulture;
try
{
if (SPContext.Current == null)
{
Thread.CurrentThread.CurrentUICulture = new CultureInfo((int)list.ParentWeb.Language);
}
// change list's title
list.Title = title;
list.Update();
}
finally
{
if (SPContext.Current == null)
{
Thread.CurrentThread.CurrentUICulture = ci
}
}
}
An update conflict has occurred, and you must re-try this action.
The object … is being updated by …, in the … process, on machine ….
To resolve this issue, clear the file system cache on all servers in the server farm. To do this, follow these steps:
ExpectedException 