SharePoint Evil #2: The URL ‘[url]’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web – The 2nd Scenario

A SharePoint Evil is an issue/error that is so ambiguous and misleading that Google will shows 50 hits, with 10 different suggested solutions, and none of them work for your particular case. (Eeerr.. so what’s described below may not work for you – but I hope it will).

I have experienced this evilness in 2 different scenarios. The 1st scenario is related to lookup columns and described here: https://bernado-nguyen-hoan.com/2011/03/22/sharepoint-evil-1-the-url-url-is-invalid-it-may-refer-to-a-nonexistent-file-or-folder-or-refer-to-a-valid-file-or-folder-that-is-not-in-the-current-web/

This will describe the 2nd scenario – which relates to duplicate ColName for fields on the list. Same as before you will get this error message when editing item properties:

The URL ‘[url]’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

If you look in the ULS, you will see the error message above, and closely before/after it, you will see an error message relating to SQL like this:

Unexpected query execution failure, error code 8143. Additional error information from SQL Server is included below. “Parameter ‘@nvarchar1’ was supplied multiple times.” Query text (if available): “DECLARE @@S uniqueidentifier; DECLARE @@W uniqueidentifier; DECLARE @@DocId uniqueidentifier; DECLARE @@DoclibRowId int; DECLARE @@Level tinyint; DECLARE @@DocUIVersion int;DECLARE @@IsCurrentVersion bit; DECLARE @@iRet int; DECLARE @DN nvarchar(256); DECLARE @LN nvarchar(128); DECLARE @FU nvarchar(260); SET @DN=N’regions/emea/admin/docs/Funding Proposals 2008-09/WE’;SET @LN=N’WESTERN EUROPE – Post Management – Funding Request.doc’;SET @FU=N’regions/emea/admin/docs/Funding Proposals 2008-09/WE/WESTERN EUROPE – Post Management – Funding Request.doc’;SET @@S=’BC4E859F-0E05-4635-91A2-044BD335D7FE’;SET @@W=’78A13FD9-2BF8-4D97-9E70-990C0D5C4E42′;SET @@DocUIVersion = 512;BEGIN TRAN; IF @@iRet <> 0 GOTO done; SET @@Level =255; EXEC @@iRet = proc_UpdateDocument @@S, @@W, @DN, @LN, ?, ?,0,2538,0,25,268,NULL,’20110418 05:00:50′,0,0,1,1,54,0,2,0,-2,NULL,1,0,NULL,1,0,0,NULL,NULL,NULL,NULL,NULL,NULL,NULL,@@DocId OUTPUT, @@Level OUTPUT , @@DoclibRowId OUTPUT,? OUTPUT,? OUTPUT,? OUTPUT, ?,?; IF @@iRet <> 0 GOTO done;  EXEC proc_DirtyDependents @@S,1,@FU; EXEC @@iRet = proc_UpdateListItem @WebId=’78A13FD9-2BF8-4D97-9E70-990C0D5C4E42′,@SiteId=’BC4E859F-0E05-4635-91A2-044BD335D7FE’,@ListID=’8306140D-F4F6-44BB-AB04-C39EF33DD759′,@ItemId=@@DoclibRowId, @NewUIVersion = @@DocUIVersion OUTPUT,@RowOrdinal=0,@ReturnRowset=1,@Size=NULL,@tp_Version=4,@ItemName=N’WESTERN EUROPE – Post Management – Funding Request.doc’,@IsDocLib=1,@MajorVersionsLimit=0,@MajorMinorVersionsLimit=0,@UserId=54,@Level=@@Level, @TimeNow=’20110418 05:07:44′, @tp_ContentTypeId = ?,@nvarchar11=?,@nvarchar12=?,@nvarchar13=?,@nvarchar15=?,@nvarchar16=?,@nvarchar7=?,@nvarchar8=?,@nvarchar9=?,@ntext2=?,@int1=?,@tp_ContentType=?,@nvarchar1=?,@nvarchar2=?,@nvarchar3=?,@nvarchar4=?,@nvarchar5=?,@nvarchar6=?,@nvarchar17=?,@nvarchar18=?,@nvarchar1=?,@nvarchar2=?,@tp_ModerationStatus=?,@tp_ItemOrder ….

This is a pretty long and meaningless message – except for the part I’ve bolded: Parameter ‘@nvarchar1’ was supplied multiple times.

This means there are multiple fields in the list pointing to the same underlying DB column in the database.

So how could this have happened? In the list XML schema we defined all the fields for the list, e.g.:


<FieldID="{c29e077d-f466-4d8e-8bbe-72b66c5f205c}"Name="URL"SourceID="<a href="http://schemas.microsoft.com/sharepoint/v3%22StaticName=%22URL%22Group=%22Base">http://schemas.microsoft.com/sharepoint/v3"StaticName="URL"Group="Base</a> Columns"Type="URL"DisplayName="URL"Required="FALSE"Customization=""ColName="nvarchar1"RowOrdinal="0"ColName2="nvarchar2"RowOrdinal2="0"/>

The ColName attribute above should NOT be specified in the schema. You should let SharePoint decides which DB column to use.

If your schema has these attributes, it will still works when you initially deploy. The problem will come when the list has been in production for sometime, and users add/remove columns to the list using the UI, and you then add additional fields to the schema, and you specified the ColName to use, and unknowingly to you, one of those ColNames is already being used by the fields added by the user (through the UI).

Unfortunately, one of the common practices for SP developers is to add the field to the list using the SP UI, then use a tool such as SharePoint Manager to extract the XML and paste it into the schema they are coding. If you do it this way, ensure that you clear out the ColName attributes (and possibly others as well) that SP has put in on a deployed list.

Advertisements

About Bernado

Based in Australia, I am a freelance SharePoint and Dynamics CRM developer. I love developing innovative solutions that address business and everyday problems. Feel free to contact me if you think I can help you with your SharePoint or CRM implementation.
This entry was posted in SharePoint, SharePoint 2010, SharePoint Evils. Bookmark the permalink.

8 Responses to SharePoint Evil #2: The URL ‘[url]’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web – The 2nd Scenario

  1. Alaina B says:

    SharePoint Evil #3: The URL ‘[url]‘ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web – The 3nd Scenario

    After reading your two scenarios I started playing around in SQL Server and began reading the error logs. I found this message “CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.”. After some further Googling I discovered that SharePoint was installed under SQL Server Express, even though we had the Standard edition installed. Not sure how that happened, but upgrading the instance resolved this error. Hope that helps someone!

  2. Ben B says:

    I just ran into this error myself. In our case it turned out to be that the transaction log for the content database had filled (we had been working on moving a large document library from 2007 to 2010 and converting to managed metadata). Had the SQL team take care of the transaction log and we were good to go.

  3. Thank you so much for writing this. This was absolutely my problem. There were two columns of the same name in my form library. I’ve spent half a day on this problem, thanks again.

  4. Daniel says:

    YOU! Sir are a lifesaver!
    I was fiddling around with that problem for like 2 weeks on and off now and could not really find out what the underlying problem is.
    (After exchanging a SP2007 with a SP2010 list template definition all the old lists created from the 2007 template did not work correctly anymore, despite checking all internal fields and IDs)
    That nvarcharXX clue hinted me to the real problem finally. Old template had 10 “nvarchars” defined where the new one had 17 wich lead to duplicate keys that I ever really considered to check because they were ordered correctly… in the schema, but not in the lists whose underlying template should be replaced.
    With this I finally could correct that ill behaviour 🙂

  5. mossonmoss says:

    In our case the error was being produced by lack of space on the sql server. Freeing up space or allocating more resolved the issue.

  6. TexasT96 says:

    I copied an existing field within the Schema.xml to use for a new field I added. Of course, I did not think to change the “ColName” field. In my mind, I was looking at the column name as a column type, since it was similar to “nvarchar10”. This mistake made me spend needless amount of time, until I found this article. Worked without issue. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s