THIS IS VERY BAD. WE ALL KNOW THAT MAKING DIRECT UPDATES TO THE DATABASE WILL CREATE SOME SORT OF BLACK HOLE AND KITTENS DIE IN REDMOND ETC, ETC. I HAVEN’T TESTED THE LONG TERM EFFECTS AND ONLY DID THIS ON MY DEVELOPMENT ENVIRONMENT TO GET ME OUT OF A PICKLE.

Disclaimer over.

If you ever get this error when trying to update a field, either through the web UI or programmatic-ally it normally means your Version fields are out of sync. This can occur if your field has been created using the Schema XML from another environment or you have migrated content using some dodgy 3rd party app.

Run this update on your content databases and you all should be good again.

UPDATE [MyContentDatabase].[dbo].[ContentTypes] SET [Version] = CAST([Definition] AS XML).value('(/Field/@Version)[1]', 'int') WHERE CAST([Definition] AS XML).value('(/Field/@Version)[1]', 'int') <> [Version]

Comment and share

For a standard team site (STS#0) the GlobalNodes SPNavigationNodesCollection will contain three SPNavigationNode objects.

Home, Quick Launch and SharePoint Top Navigation Bar, these each have Ids of 1000, 1002 and 1025 respectively.

The problem occurs if you delete Quick Launch or SharePoint Top Navigation nodes. Even if you then add them back in a new ID is generated and SPWeb.Navigation.TopNavigationBar looks for child nodes under a node with an Id of 1002 (This is hard coded).

Through the API this means that SPWeb.Navigation.TopNavigationBar will always be null and through the SharePoint UI an error will be returned to the user (“Value does not exist in that range”).

The only ways I have found to fix this is to delete and re-create the site or (Microsoft please close your ears) get the site id and web id and query the NavNodes table in the content database the site collection sits in and add the following records

SiteId WebId Eid EidParent NumChildren RankChild ElementType Url DocId Name DateLastModified NodeMetaInfo NonNavPage NavSequence ChildOfSequence
C803FD13-27FA-475F-909C-2CE5B2048E1B A31E8093-1505-4E1C-B7CC-04D6B952A33F 1000 0 0 0 0 NULL A31414EE-953B-44CC-A37E-4D5D643B002A Home 2008-04-04 11:28:21.000 NULL False False False
C803FD13-27FA-475F-909C-2CE5B2048E1B A31E8093-1505-4E1C-B7CC-04D6B952A33F 1002 0 0 2 1 NULL NULL SharePoint Top Navigation 2008-04-04 11:28:21.000 NULL False True False
C803FD13-27FA-475F-909C-2CE5B2048E1B A31E8093-1505-4E1C-B7CC-04D6B952A33F 1025 0 0 1 1 NULL NULL Quick Launch 2008-04-04 11:28:21.000 NULL True True False

Comment and share

I have been trying to rebuild a development environment recently using DBA created tables.

Every time I ran the PSCONFIG -cmd configdb -create command it ran and then threw an error.

The error message above was logged.

After looking through the tables, I noticed that some of the tables in both the config db and the config admin db had been created under the user account I had been running the installation under and some had been created under dbo.

There are a couple of SQL scripts in the layouts folder under SQL that are run to create the schemas and here I think is the problem.

Most of the CREATE TABLE statements using the following syntax CREATE TABLE [dbo].[TableName], but there are a few tables in both databases that just use CREATE TABLE TableName.

The error occurs because further SQL script is then referencing [dbo].[TableName], but these tables don’t exist under the dbo user schema, so it errors.

The solution is to change the SQL scripts so all CREATE TABLE statements have [dbo]. infront of them. Before you run it again you will need to clear out all the objects from both the databases.

We have some rather quirky database rights in our environment, but the install account and the farm service account both had dbcreator and secuirtyadmin rights and were in the db_owner role for each of the databases.

Comment and share

  • page 1 of 1
Author's picture

Toby Statham

Independent Office 365 / SharePoint Specialist and an associate consultant at aiimi.com, an Information Management company.

Independent Office 365 / SharePoint Specialist

Brighton, UK