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();

Tagged: SharePoint Development, SharePoint Troubleshooting

§ 4 Responses to SharePoint Dev Error: Exception from HRESULT: 0x80040E14

• william says:

  June 2, 2010 at 3:17 am

  harePoint is a fastest growing product and is implemented by over 18000 companies all over the world. It provides you various benefits

  Helps you to share work files from a central place.
  Helps you to create, manage, and store content across the organization using document library.

  o Provides access control and revision control in the document library.

  o Enables you to create interactive reports in a consistent way throughout the organization.
  o Enables you to connect and collaborate with other individuals or team in the organization regardless of where they are located by creating information portals on Intranet, Extranet, or Internet sites. 

  Reply
• jasear says:

  January 27, 2011 at 4:37 am

  I think you have fixed the issue but credited the fix to something else.

  This error is generated by the DB Server. It usually happens when your server does not have enough space to create transaction logs or store more data.

  I really dont think there is any connection with the display name or internal name.

  Reply
• NIS says:

  November 22, 2011 at 3:45 am

  +1 for jasear, I have the same problem here and seems like low disk space is the cause of the problem.

  Reply
• Kiran says:

  December 1, 2011 at 10:47 pm

  I think this is because of field name issue and not the disk space.

  Reply