Hi everyone, just wanted to post a quick note to let you all know that my blog is undergoing a few changes, one of those being a new hosting company, Rackspace. There are a few things that have not quite been cut over properly, so I’ll be dealing with those in the next couple of days. If anyone notices anything, please let me know!
Archive for September, 2009
Alright, today’s blog post is going to be a bit infrastructure related. More specifically, I’d like to document an issue we encountered recently trying to do a restore from a production server to one of our development boxes. We do this often to keep our development data fresh and in sync with production, otherwise it becomes difficult to do any sort of real testing with numbers. Usually, this is a pretty standard procedure for us:
- Within Central Administration, under Application Management, we navigate to Content databases
- Making sure to select the Web Application we plan to restore to, we click on the WSS_Content link (or whatever happens to be the name of your db)
- Within the Manage Content Database Settings page, change the Database status drop down from Ready to Offline
- From here I stop the IIS Web Site, restart SQL Server and kick off my restore
- Once the restore is complete, I head back into my Manage Content Database Settings page and switch the Database status back to Ready
Now usually this works without issue. But recently, while attempting to do this on a machine we hadn’t worked with on a few weeks, we were encountering all sorts of errors trying to navigate to our site collection. Specifically, we were seeing the following error in the Operations logs:
The specified SPContentDatabase Name=WSS_Content Parent=SPDatabaseServiceInstance Name=Microsoft##SSEE has been upgraded to a newer version of SharePoint. Please upgrade this SharePoint application server before attempting to access this object.
Based on this error, my first thought was to check the dbo.Versions table to see if perhaps we had a conflict in versions as this error would suggest. Unfortunately, trying to read from the dbo.Versions table resulted in this pretty error:
Msg 33002, Level 16, State 1, Line 1
Access to table dbo.Versions is blocked because the signature is not valid.
So now we’re having fun at this point. I can’t read from the dbo.Versions table, so I don’t really know what the patch level of this particular server is. After checking production, I know that my patch level is 12.0.0.6504. In order to cross check what this means, you should have this link handy from the SharePointDevWiki.
Based on what I was reading there, my production server had the: MOSS 2007 or WSS 3.0 April 2009 Cumulative update. I know I probably could have done the research and checked file versions, but why should I have to do that when all I really needed to do was read from dbo.Versions? After a bit of troubleshooting, I realized it would make the most sense to simply spin up a new Web Application and fresh content db on my development box and read ITS dbo.Versions table. Turns out that original error was right on the money, my development box was one version behind: 12.0.0.6421.
Once I upgraded to the missing cumulative update and tried my restore process again, everything was back to normal! I hope that helps someone understand what the dbo.Versions table is all about, and what you can do to get past these errors.
If you’re like me and you do a fair bit of object model programming, you’ve likely seen this error before. More specifically, the error is as follows:
Unhandled Exception: Microsoft.SharePoint.SPException: Invalid data has been used to update the list item. The field you are trying to update may be read only.
There are probably more than one cause for this particular issue, but in my case, it always comes down to an error in the way I’ve assigned a field of type Lookup.
So to set up our scenario, let’s say we have a custom list called Types, and it contains 3 items:
- Employee
- Contractor
- Manager
Now let’s assume we’ve created a custom list called Users and it contains a column called User Type of type Lookup that points to the Types list using the Title column.
If we’re doing some updates to our list programmatically, we’ll need to be able to set the Type column. Your typical scenario is that you’re reading this from a form control and populating this field. In my case, I knew specifically what value I wanted to set. So let’s start with something like this:
1 2 3 | SPListItem item = list.Items.Add(); item["Type"] = "Employee"; item.Update(); |
Unfortunately, the above bit of code will fail with the error outlined at the beginning of this post. The data we’re attempting to assign is not valid. What we need to do is create another object, an SPFieldLookupValue object to be more specific, and use one of the constructors to build the lookup that we’ll then assign to our field.
1 2 3 4 | SPListItem item = list.Items.Add(); SPFieldLookupValue lookup = new SPFieldLookupValue(1, "Employee"); item["Type"] = lookup; item.Update(); |
I’m not satisfied with the above, because it’s forcing me to hard code the id and the value. I am interested in some feedback from my readers — does anyone have a better approach to this problem? I’ll be awarding a free Black Ninja TSHIRT to the reader who can provide me the most elegant workaround.
I’m very excited and I consider myself quite lucky to be able to attend the Microsoft SharePoint 2009 Conference in October. I’ve already been to a couple great conferences this year, but I am quite confident this will be a good one. I’m looking forward to seeing all that 2010 has to offer.
If you haven’t already, you might want to check out the preview videos over at the Microsoft SharePoint site.
I love jQuery. I work with it quite a lot on various projects. One of the coolest features in my humble opinion is AutoComplete. There are a ton of different plugins you can work with, some are variations of others, but for the most part, they work pretty darn good out of the box.
I have been trying unsuccessfully over the past hour or so to pass in the value of a checkbox as a parameter to my AutoComplete plugin as follows:
1 2 3 4 5 | cacheLength:0, minChars:2, max:20, autoFill:false, extraParams: { active : $('input[name=status]').is(':checked') } |
Now the issue I was encountering was regardless of what the state of the checkbox was, checked or unchecked, the AutoComplete plugin always returned it’s initial value. So if by default it was unchecked, it always returned false. If by default it was checked, it always returned true.
After a bit of digging, I finally stumbled across this site that explains that the value is locked in once the AutoComplete plugin is initialized: http://stackoverflow.com/questions/1216222/jquery-passing-checkbox-values
So to solve the issue:
1 2 3 4 5 6 7 8 9 | cacheLength:0, minChars:2, max:20, autoFill:false, extraParams: { active : function() { return $('input[name=status]').is(':checked'); } } |
Awesome! Thanks to Stack Overflow and redsquare!