When ever you try deleting an object from reporting service 2005 report manager, it fails with the following error stack in the log file (<Installation Directory>:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\LogFiles\ReportServer_TimeStamp.log)

w3wp!library!12!07/13/2010-08:56:28:: a ASSERT: Assertion failed!   Call stack:
 Microsoft.ReportingServices.Library.DeleteItemAction.PerformActionNow() 
 Microsoft.ReportingServices.Library.DeleteItemAction.PerformActionInBatch(CallParameters parameters) 
 Microsoft.ReportingServices.Library.RSService.ExecuteBatch(Guid batchId) 
 Microsoft.ReportingServices.WebServer.ReportingService2005Impl.ExecuteBatch() 
 Microsoft.ReportingServices.WebServer.ReportingService2005.ExecuteBatch() 
 System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) 
 System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) 
 System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) 
 System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) 
 System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values) 
 System.Web.Services.Protocols.WebServiceHandler.Invoke() 
 System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest() 
 System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context) 
 System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() 
 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) 
 System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(Exception error) 
 System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) 
 System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) 
 System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr) 
 System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType) 

w3wp!library!12!07/13/2010-08:56:28:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details., un-named assertion fired for component library;
 Info: Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details.

No matter what previlege the user has, it will still fail.

With SQL you can set nocount on for all users which turns off the message returned at the end of each statement that states how many rows were affected. SSRS 2005 relies on this and NOCOUNT must be disabled for SSRS 2005 Stored procedures to work correctly. This can be verified and fixed as follows:

How to Fix this issue?

There are two possible reasons for this error:

1. DBA turned on global nocount setting for all users (user option 512).

Check if user options with 512 is set:
So execute:

EXEC sp_configure 'show', 1
RECONFIGURE WITH OVERRIDE
EXEC sp_configure


Check the "run_value" column for the "user options" item. To verify if bit 512 is set, execute this:

IF (<PlaceTheValueHere> & 512) > 0
PRINT 'TRUE'
ELSE
PRINT 'FALSE'


while replacing <PlaceTheValueHere> with the value obtained from the run_value for "user options".

If the option is set, you can reset it using the following statements:

First calculate the new value by,

SELECT <PlaceTheInitialValueHere> & (~512)

Place the above result in the sp_configure statement:

EXEC sp_configure 'user options', <PlaceTheResultHere>
RECONFIGURE WITH OVERRIDE

IMPORTANT! Changing the option may interfere with other applications which are using the SQL Server.

After changing the value, try testing the delete operation or try changing the Data Source properties again.

2. Traceflag 3640 does the same thing. 3640 eliminates the sending of DONE_IN_PROC messages to the client for each statement in a stored procedure. This is similar to the session setting of SET NOCOUNT ON, but when set as a trace flag, every client session is handled this way.

See if any trace flags enabled by running the following Query,
DBCC TRACESTATUS(-1)

If the trace flag is enabled, you can disable it using this statement:

DBCC TRACEOFF(3640, -1)

HTH!

Selva

[All the posts are AS-IS and doesn't carry any warranty]