I told myself I was going to stop blogging about SharePoint 2007 stuff but this one may apply to 2010 as well. And it took me and a cohort nearly 3 days to figure out.

Scenario:

The project is using MOSS 2007 as a Supply Chain Management Application Platform. A SharePoint data access layer (DAL) was built to speed development across the development teams so that they didn’t have to worry about the intricacies of working with the SharePoint object model. The data primarily resided within a single SharePoint list and consisted of ~80 columns and > 100,000 list items. My part was to create a custom Edit/Display/Version History form web part that would render data according to custom user roles, rights, and various other criteria. For example, User A can see 50 fields, write to 10 fields and see 40 as read-only data. User B can see 20 fields, write to 5 fields and see the rest as read-only data. The custom web part also utilizes the DAL to update SharePoint list items with new data.

Problem:

Upon saving the data back to SharePoint using the custom DAL, the version history was incremented but none of the form data was being written back to the SharePoint list item. As we were debugging the issue, we came across the following exceptions and errors messages from Visual Studio and the SharePoint diagnostic logs.

Exception from HRESULT: 0x80040E14

Source = “Microsoft.SharePoint”

StackTrace = ”   at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, …

Windows SharePoint Services | Database | 6f8g | Unexpected

Unexpected query execution failure, error code 8145. Additional error information from SQL Server is included below. “@tp_ID is not a parameter for procedure proc_UpdateListItem.” Query text (if available): “BEGIN TRAN;DECLARE @@iRet INT,@DN nvarchar(256),@LN nvarchar(128),@@S uniqueidentifier,@@Level tinyint,@@DocUIVersion int,@ExtraItemSize bigint;SET @@iRet = 0;SET @@S=’B1DA1F55-D16D-4E46-9FB8-F0B4795368EB’;SET @@Level=1;SET @@DocUIVersion = 512; SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_UpdateListItem @SiteId=’B1DA1F55-D16D-4E46-9FB8-F0B4795368EB’,@WebId=’5ABC8FE7-112D-40A9-A2B7-F731F620F549′, @ListID = ‘37386B71-16F1-4EC4-BF4B-80B83F847F0E’, @ItemID=1759, @RowOrdinal = 0,@ReturnRowset = 1,@ItemDirName=@DN OUTPUT,@ItemLeafName=@LN OUTPUT,@UserId=1,@TimeNow = ‘20100527 15:09:30’,@Ma…

Windows SharePoint Services | Database | 8e2s | Medium

Unknown SPRequest error occurred. More information: 0x80040e14

Solution:

My unnamed cohort really gets the credit for this one. In the DAL, all the SPListItem field updates were referencing internal field names. For example:

SPListItem item = some item you get from SharePoint;
item[internalFieldName] = “some value”;
item.update();

Usually, that would work just fine and is typically the preferred method since often times the field display names can be changed through the user interface rendering your code useless. But it simply wouldn’t work in our situation. After modifying the DAL to update the items using the display names, everything worked as expected! What a cockeyed bugger right?

SPListItem item = some item you get from SharePoint;
item[displayFieldName] = “some value”;
item.update();