Monthly Archives: August 2014

KB2775511 – Blowing up my Usage Data Import Timer Job

This issue is described here: http://support.microsoft.com/kb/2916922 

This patch (along with  KB2682011 or KB2882822) could cause the Usage Data Import timer job to not import the .Usage files into the Usage Logging Database. When this timer job runs you will notice the following in the ULS logs:

OWSTIMER.EXE (0x51A0) 0x59E4 SharePoint Foundation Usage Infrastructure a5rv High Failed to delete usage log file ‘E:\Logs\ServerName-20130701-2117.usage’ after data import. Exception: System.IO.IOException: The process cannot access the file because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileInfo.MoveTo(String destFileName) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.MoveFileOrDirectory(FileSystemInfo fi, String newPath) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DeleteFileOrDirectory(FileSystemInfo fi) at Microsoft.SharePoint.Administration.SPUsageLogImporter.ImportUsageLogFiles(List`1 usageLogFileList)

This causes a few unwanted side effects: The usage logs will grow as they are not getting imported and purged and this timer job will take a looong time to run and can cause your timer service recycle timer job to fail. I was manually restarting the timer service each day for a while, but we ended up uninstalling the patch as a longer term solution. This issue is fixed in the December 2013 CU, but that was not an option in this case.

This is why I always recommend you have a test environment…This was caught before it got pushed to PROD!

-AJB

SharePoint List Error – Exception from HRESULT: 0x80131904

Short version – This was fixed with the following procedure:

  1. Go into List Settings for the list in question
  2. Under columns I clicked the Column Ordering link
  3. Changed Title’s position from Top to be 1 (It was 2 from the top in my case)

Explanation – This list had a lot of columns (60 to be exact). After further research there’s something unique that happens when you have 16 columns in a list. Any time someone creates 16 columns in a list and then sets any column that was created in position 16+ to position 1 (It doesn’t matter the type of column) in the list you will receive that error.

Technical Explanation:  The problem here is because SharePoint utilizes SQL server row wrapping to allow a maximum number of columns in a SharePoint list where SharePoint Server will create several rows in the database when data will not fit on a single row. This is controlled via the property RowOrdinal, which identifies which row a certain field should be stored. When RowOrdinal = 0, the field is stored in the first row of the row set for that list item and when RowOrdinal = 1, the field is stored in the second row of the row set for that list item.

Lets take a look at this in action:

  1. Save list as template, open Manifest.xml
  2. Find the <Fields> Section (Notice The RowOrdinal values??)<FieldName=”Test_Task” Version=”2″ DisplayName=”Test Task” Type=”Choice” RowOrdinal=”1″ ColName=”nvarchar35″ StaticName=”Test_x0020_Task” SourceID=”{f62365c4-32fa-4f67-a714-963aa49a3f8a}” ID=”{402b7fff-701c-45b4-bc06-ffaf51dd3fe8}” FillInChoice=”FALSE” Format=”Dropdown” Indexed=”FALSE” EnforceUniqueValues=”FALSE” Required=”TRUE”><FieldName=”Title” Version=”2″ DisplayName=”$Resources:core,Title;” Type=”Text” RowOrdinal=”0″ MaxLength=”255″ Indexed=”FALSE” EnforceUniqueValues=”FALSE” ColName=”nvarchar1″ FromBaseType=”TRUE” StaticName=”Title” SourceID=”http://schemas.microsoft.com/sharepoint/v3” Required=”FALSE” ID=”{fa564e0f-0c70-4ab9-b863-0177e6ddd247}”/>

Errors in ULS Logs:

System.Data.SqlClient.SqlException: Cannot insert the value NULL into column ‘tp_DocId’, table ‘SP2010_Content_10030.dbo.AllUserData’; column does not allow nulls. INSERT fails. The statement has been terminated.

This issue is similar to http://blogs.msdn.com/b/allenwang/archive/2012/05/21/sp2010-survey-list-error-and-event-id-5586.aspx