Archive for August 26th, 2009


Indexed Columns in SharePoint 2007

Here is a great in-depth article on what happens when you define an index on a SharePoint column.  You get to the Indexed Columns functionality by going into the settings of a list or library and looking at the links at the bottom of your column list.

Indexed Columns

It’s very simple to check a box next to a column you want to index, but be aware, you are NOT creating a true SQL Server index.  What you are doing is putting the values of the column in a name/value pair table and SharePoint is using these entries in a join to the UserData table in an attempt to increase performance when you have thousands or millions of items in a list or library.

My experience has shown that, in our situation where we have libraries with up to 40,000 items and custom SharePoint applications querying those libraries, we are not seeing any significant performance increase.  Your mileage may vary.


SharePoint View Not Returning Items Defined in Filter

Our team was testing a custom SharePoint app that had some recent modifications made to it and we were finding that it wasn’t returning results that we were expecting – and had in the past.  The programmer couldn’t find any unexpected changes in the CAML queries that were being used in the code.  We were all struggling trying to figure out what was going on.

I was doing some troubleshooting by creating views in SharePoint on the offending libraries to filter the items we were looking for and I found that some of these views weren’t functioning correctly.  One of the things I noticed when creating some views of the libraries that were giving us the problems was there were some SharePoint “indexes” defined on a couple of the fields.

For those not familiar with SharePoint indexes, they are not true relational indexes that you would create in a SQL database.  Instead, they involve some clever joins to supposedly increase the performance of list views. 

I found that, at some point in time, we had created some of these indexes.  When creating the view in SharePoint, you could see the fields that had indexes defined because they had the word (Indexed) next to them.  Trying to filter on these fields was giving us unexpected results.  In fact, in one of my test cases, the filter wasn’t working at all and no results were being returned.

To solve this problem all I did was turn off the indexing on the fields in SharePoint (under library settings).  After that, the filters in the views started working.  Plus, in our application, we began getting the results we expected.  Problem solved!


The web application at [URL] could not be found. Verify that you have typed the url correctly. If the url should be serving existing content, the system administrator may need to add a new request url mapping to the intended application.

I was recently working on a custom windows application whose job was to bulk load content into SharePoint document libraries.  I was testing it on the test server and then moved it over to the production server for the client to use.  When they logged in with their admin account (account #1) and fired up the app, it wouldn’t do its job.  Looking at the log file showed the error:

The web application at [URL] could not be found. Verify that you have typed the url correctly. If the url should be serving existing content, the system administrator may need to add a new request url mapping to the intended application.

This error is basically a really verbose SharePoint “file not found” type of error.  It’s saying that it can’t find the URL and suggesting that your SharePoint administrator might need to add an alternate access mapping to your SharePoint web application (extend the web app and add an alternate access mapping).  It was occurring when instantiating and SPWeb object.

The funny thing about this error was that, if I logged on as an administrator, it went away and the app worked fine.  That immediately suggested to me I had a permissions problem.  So I looked all around for where the differences might be.  The account was actually in the domain administrators group and had permissions that worked fine in SharePoint.  It was a farm administrator and a site collection administrator.  There was nothing it couldn’t access…except the SPWeb object. 

We had a couple of other accounts that were similarly configured, so I tried one of the other accounts after spending hours “googling” (or was it “bing-ing?) a potential solution.  While searching on the web, I found I had plenty of company with others who had similar problems.  Many of proposed solutions revolved around swapping out accounts in specific application pools being utilized by SharePoint.  However, most of these solutions do not take into account infrastructures that won’t allow these accounts to be changed to local system accounts.  Whatever…

Okay, so I tried one of our other similarly configured accounts and found that it worked just fine.  “What was the difference”, I pondered?  I searched all over and found that account #2 was NOT a site collection administrator.  In other words, the account that wasn’t working, account #1, WAS a site collection administrator and the account that WAS working was not.  So, I removed it from the site collection administrators.

Guess what?  My application suddenly started working when logged on as account #1.  So, I put it back in to the site collection administrators group and found that it STILL WORKED!  Just taking it out of the site collection administrators did something, somewhere in the vast security netherworld of SharePoint that flipped the appropriate “bit” and fixed whatever the original problem was.  Problem solved.  Only took eight hours.  😦

Asif Rehmani’s SharePoint Videos


Click to access a wealth of SharePoint videos

SharePoint Rx

SharePoint Rx Home


Posts by Date

August 2009
Support Wikipedia