Can't edit items from a particular list? Corrupt somehow?

Question

I can't seem to edit any list item in a particular list. The stack trace points to the AddOrUpdateItem() method (below). I can't think of any recent changes made to the content type of list definition that would cause it and this list was fine up until recently (no distinctive tasks performed, other than a few item edits, worth noting):

<nativehr>0x8000ffff</nativehr><nativestack></nativestack>

Stack Trace:

[COMException (0x8000ffff): <nativehr>0x8000ffff</nativehr><nativestack></nativestack>]
   Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish, String bstrFileName, ISP2DSafeArrayWriter pListDataValidationCallback, ISP2DSafeArrayWriter pRestrictInsertCallback, ISP2DSafeArrayWriter pUniqueFieldCallback) +0
   Microsoft.SharePoint.Library.SPRequest.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bUpdateNoVersion, Int32& plID, String& pbstrGuid, Guid pbstrNewDocId, Boolean bHasNewDocId, String bstrVersion, Object& pvarAttachmentNames, Object& pvarAttachmentContents, Object& pvarProperties, Boolean bCheckOut, Boolean bCheckin, Boolean bMigration, Boolean bPublish, String bstrFileName, ISP2DSafeArrayWriter pListDataValidationCallback, ISP2DSafeArrayWriter pRestrictInsertCallback, ISP2DSafeArrayWriter pUniqueFieldCallback) +406

I'd like to give a bit more context but I honestly don't know what else to troubleshoot.

Note, this isn't item specific.

The logs don't reveal anything other than what the stack trace does.

Any pointers in the right direction greatly appreciated.

Please also note - this has happened before. Tearing down the list and rebuilding and repopulating it resolved it, but that isn't an issue now due to content.

Answer 1

Same issue i faced recently, but resolved with lot of research.

The above mentioned issue will come duplicate columns exist in your List schema file. verify your List schema once.... Still the problem exist, follow the below trick

verify your "ColName" attribute for every Field, it should be UNIQUE for every Field. because Colname attribute defines the mapping of the field to the physical storage name for this field. This must be a valid name in the underlying database and must be identical to the name used in the database table.

For more details :

http://msdn.microsoft.com/en-us/library/ms437580.aspx

So please mention unique ColName for every Field in the List schema, but my suggestion is in the list schema file dont mention this Colname attribute for the List Fields, SP will take care of this.

Hope this helps... Happy Coding :)

Or there exists indexes on same column in the list.

Answer 2

Agreeing and summarising both Hugh and David above, this is corruption somewhere along the line, and sometimes an IISReset fixes it.

The corruption may be within the list itself or in a column defintion - so make sure you have a recent content database backup handy before you delete the list.

I'd recommend recreating the list and somehow get the items out of there and into the new one (try with Datasheet view to copy/paste items across first).

Before you do wipe the list, save it as a template (with content, if it's not too big), and see if you can move it and replicate it on a different environment. This will absolutely prove that the list is at fault, and nothing else.

HRESULT exception codes like that are spat out back by the COM server underlying SharePoint, and normally we (developers) see them if we have a malformed CAML Query. 0x8000FFFF doesn't ALWAYS mean corruption, it's just a completely untrapped error (or 'catastrophic failure'). Causes for it when updating a list could be a wide range of things, including malformed Calculated Column formulas, malformed User fields, or someone somehow managing to inject some kind of code into a field that's not properly escaped before being fed to the database.