Monday, April 17, 2017

List view error: Attempted to use an object that has ceased to exist

List view  error: Attempted to use an object that has ceased to exist

Error Scenario:
In SharePoint, when navigating to a list view page (ex: 'All Items' view), or to a site page (like home page) that contains a list view web part, the page crashes, throwing the following error:

Server Error in '/' Application.

Attempted to use an object that has ceased to exist. (Exception from HRESULT: 0x80030102 (STG_E_REVERTED)) 

Root Cause:
The error is thrown because of the resource throttling in that list. The GroupBy is counting & folding too many items causing SharePoint to prevent the SQL server from processing the view query. When checking the number of items in list settings page, it shows it had 18670 items (way above the default list view threshold of 5000).

The fix is to enable larger resource throttling for the target web application.
Example: In this case I set to 20000.

From Central Administration site > Manage Web Applications > select target web app > General Settings > Resource Throttling > change List View Threshold > OK

Note: there is a reason of why Microsoft set the default theshold into 5000 which is to avoid getting a performance hit on SQL server by queries on too many items. When you have very large lists or libraries, try to think about alternative approaches to divide the data, such as split into multiple lists, or using folders in case of document libraries.

SQL Deadlocks and the Project Server Queues

SQL Deadlocks and the Project Server Queues

on SQL deadlocks and error messages like the following on a busy server.
System.Data.SqlClient.SqlError: Transaction (Process ID 84) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
You will also see error id 7747 in the application event log.
This can be an issue with systems that are quite stressed and in all cases I have seen relates to the process that selects the queue jobs for processing. It does not break anything as such and no data is lost – but processing of queue jobs is delayed (but as the system is very busy they probably wouldn’t have processed quickly anyway!).
Deadlocks occur when two transactions interact in such a way that one requires a resource that the other has locked, and vice versa. Because neither task can continue until a resource is available and neither resource can be released until a task continues, a deadlock state exists. SQL Server selects one of the transactions as the victim and ends it – and posts the above error.  See the SQL Server Books Online for more details.
In Project Server 2007 you can monitor activity using perfmon, and the counters include SQL retries per minute for both the Project and Timesheet queues. You can also modify the queue settings which can reduce the occurrence or behavior of the deadlocks. We don’t have any prescriptive guidance yet on suggested changes, but certainly reducing the number of threads, increasing the polling interval, or increasing the SQL retry intervals would likely reduce the number of deadlocks you see. However, these changes will also reduce the throughput of your queue – particularly when processing light weight jobs. If you see the deadlock behavior at specific time of day only – and want to change queue settings to suit workload you could even use the QueueSystem web service to change the settings (using the SetQueueConfiguration method).
I’m not sure if anyone will really want to micro-manage their queue in this way – or what the overall throughput benefits would be – but the option is there.

How to export a schema.xml file for a list from a SharePoint site

How to export a schema.xml file for a list from a SharePoint site In sharepoint, we can retrieve the XML schema of any list by using ...