Last year we at PeopleNet ran into a problem when using lists with many columns, i.e. around 1600!

Indexing such a list would almost always fail with a timeout or out of memory error in the log, even though SharePoint is supposed to be able to handle at least 2000 columns without performance issues.

We corresponded back and forth with a Microsoft support engineer about the problem and it turned out that lists with many multiple value lookup fields will bring the SQL Server to its knees fairly quickly.

Microsoft has recently released a KB article in relation to this, however, it doesn’t specifically single out multiple value lookup fields as the culprit, although they almost always are.

From time to time you may encounter that a user on a publishing site is denied access to creating pages, even if the Create Page link in the Site Actions menu hasn’t been security trimmed.

This is probably due to the user not having read access to the the master page gallery.

Solution

To remedy the problem, go to Site Actions > Site Settings > Modify All Site Settings > Master Page and Page Layouts. This takes you to the master page gallery.

Now go to Settings > Document Library Settings > Permissions for this Document Library and give the user (or the group he belongs to) read permission.

As most companies are moving to the 64-bit platform of Windows Server and MOSS, more SharePoint developers are adopting this as their main dev environment.

However, if you plan to develop SharePoint workflows in Visual Studio 2008 on your new 64-bit box, you’re going to be disappointed.

Upon creating a new workflow in VS, an “Object reference not set to an instance of an object”-error pops up:

You can still get to the next step in the process where you have to chose the site which will be used to debug the workflow. Here too, you will be faced with an error:

The solution

Well, there isn’t any. Not right now anyway.

The only thing you can do is to continue developing in your old 32-bit environment and then move your WSP to the 64-bit box for installation.

All this is not a bug per se, rather, it’s down to Microsoft’s lack of resources in their dev team:

 
(source)

Hmm…

Many of you have probably encountered the problem where a workflow triggers itself several times because the code carries out one or more Item.Update() commands. This can be extremely annoying because running extra workflows can be taxing on the server – even if you make sure that the extra workflows don’t make any changes to the element.

Then, you may have discovered Item.SystemUpdate() which in theory should rid the list of the all the extra instances of workflows because it doesn’t trigger an update event and thus flies under the radar of the workflow engine.

This seemed to work just fine for a while. Lately, however, it seems that SystemUpdate() has startet triggering events just like a normal Update().

Post Service Pack 1?

I found that many of my workflows now started behaving differently, i.e. they began triggering multiple instances of workflows.

It took me a while to realise that it probably was a “bug fix” in SharePoint SP1 that was causing the problem.

A glance at the documentation for SystemUpdate() reveals that events are indeed triggered:

There is no mention of SP1 but I assume that this was when the changes were made.

Solution

This is bad news for many developers but obviously a design decision at Microsoft so things probably won’t be changed back to the way they were.

From now on you have to make sure that your workflows only make changes to elements when needed. I.e. you need to only use Update() and SystemUpdate() when they are really needed and thereby minimise the number of redundant workflow cycles.

Alternatively, you could look into programming your own event handlers to obtain more granular control of when events are triggered. I may explore this subject in a future post.

If you have worked with a localised version of SharePoint you may have encountered the annoying RTF editor script error.

Basically, the problem renders all instances of the RTF editor unusable, across the MOSS installation due to a common javascript error.

Symptoms

Every time a user opens an RTF editor and starts typing, a JavaScript error is fired, making typing almost impossible. This problem seems to be present in only some installations of SharePoint with regional language packs installed.

Here’s a screenshot of a Danish RTF editor with the script error:

The screenshot is from an English MOSS server with  the Danish language pack installed.

As annoying as the script error may be, it’s even more aggrevating that the error doesn’t occur on all servers with this exact setup. This means you can’t predict if a server is going to have this problem, purely based on the configuration.

Cause

The problem seems to be caused by bad code in one or more of the JavaScript files in the LAYOUTS folder. As you may know, the LAYOUTS folder is common for all sites on the MOSS server, i.e. all folders named _layouts is mapped to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.

I can only speculate about how this can happen, but perhaps some versions (but not all) of the language packs include faulty JavaScript files. This could explain why this problem doesn’t occur on all MOSS servers with language packs.

Solution

Microsoft hasn’t released any fixes to counter this problem and there is no indication as to when or, indeed, if this will happen.

Obviously, my client needed a fix ASAP and this is what I came up with:

First, I installed Fiddler HTTP Debugger to determine which JavaScript files load when the RTF editor is launched.

Fiddler came up with the following list of files:

Note that 1030 directory is where the Danish files are located (1033 is English).

I now had a fairly good idea of where the bug was located but I didn’t have the patience to go through all that JavaScript code! Instead I copied the above 7 files from a healthy MOSS server (with Danish language pack) – and lo and behold – everything worked just fine.

My money is on HtmlEditor.js as the most likely culprit but I haven’t checked up on this.