Reporting Services report

Just wondering if anyone would know why a report would work fine for around
a week, running within 6-7 seconds, then suddenly take 25 minutes to run?
Doing an update stats appears to cure the problem. The source database is
loaded several times each day. Running the SQL statement directly in SQL
Management studio, even before the update stats is done, retrieves the data
in seconds, so it wouldn't appear to be a SQL problem. I have seen articles
hinting at reporting services having its own statistics collection? but only
where cubes are involved, there is no cube in the data this report needs. We
are running SQL server 2005 service pack 2.
thanks for any help in advance
Mikey :o)Is this against a stored procedure. RS does not have its own statistics
collection against SQL Server (I have no experience with cubes but I don't
it there as well). There is an issue for some stored procedures (I haven't
seen this but it might occur more in your type of environment). If a stored
procedure you might try using the Recompile option on the stored procedure.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Mikey :0)" <Mikey0@.discussions.microsoft.com> wrote in message
news:F8215493-7817-47F5-9DD8-6E3C1026A692@.microsoft.com...
> Just wondering if anyone would know why a report would work fine for
> around
> a week, running within 6-7 seconds, then suddenly take 25 minutes to run?
> Doing an update stats appears to cure the problem. The source database is
> loaded several times each day. Running the SQL statement directly in SQL
> Management studio, even before the update stats is done, retrieves the
> data
> in seconds, so it wouldn't appear to be a SQL problem. I have seen
> articles
> hinting at reporting services having its own statistics collection? but
> only
> where cubes are involved, there is no cube in the data this report needs.
> We
> are running SQL server 2005 service pack 2.
> thanks for any help in advance
> Mikey :o)|||Bruce, thanks for responding, the report currently doesn't use a stored
procedure, it was one of the options I was considering as a work-around as it
appears the it might be something that Reporting services is doing with the
SQL command? I was thinking that by taking the SQL out of the report and
instead calling a Stored procedure, it would not be able to change the sql.
This is backed up by the fact that when this report runs slowly, the SQL can
be executed in query analyser with no problems.
"Bruce L-C [MVP]" wrote:
> Is this against a stored procedure. RS does not have its own statistics
> collection against SQL Server (I have no experience with cubes but I don't
> it there as well). There is an issue for some stored procedures (I haven't
> seen this but it might occur more in your type of environment). If a stored
> procedure you might try using the Recompile option on the stored procedure.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Mikey :0)" <Mikey0@.discussions.microsoft.com> wrote in message
> news:F8215493-7817-47F5-9DD8-6E3C1026A692@.microsoft.com...
> > Just wondering if anyone would know why a report would work fine for
> > around
> > a week, running within 6-7 seconds, then suddenly take 25 minutes to run?
> > Doing an update stats appears to cure the problem. The source database is
> > loaded several times each day. Running the SQL statement directly in SQL
> > Management studio, even before the update stats is done, retrieves the
> > data
> > in seconds, so it wouldn't appear to be a SQL problem. I have seen
> > articles
> > hinting at reporting services having its own statistics collection? but
> > only
> > where cubes are involved, there is no cube in the data this report needs.
> > We
> > are running SQL server 2005 service pack 2.
> >
> > thanks for any help in advance
> >
> > Mikey :o)
>
>

Reporting services Installation Error

I've just tried to install SQL Reporting services on my development workstation.

I was going well but suddenly I got an error that my SQL server instance is not supported.
I am running SQL Server 2000 desktop edition, service pack 3.0.

Is that true that is is not supported or it is just a bug in installation ?

Thanks

MikhailIt is possible that this version of SQL is not supported or that you have the wrong version of reporting services..

I came across an issue because we have developer edition on our Development server and 'regular' version on production.

When we ordered the CD we got a copy for production and it will of course not install on our dev server. I had to use the 120 day version while I wait for a proper version to arrive.

Reporting Services Form Authentication - w3wp.exe kernell32.dll Er

Hi,
I have developped a Form Authentication extension for Reporting Services
which used to work just fine on a certain server. Suddenly, for "no apparent
reason" (I had not personnaly changed the configuration of anything on the
server), Report Manager stopped working (but the Report Server still is
working).
I don't see anything wrong (i.e. no ERRORS) in the Reporting Services
LogFiles but in the Windows Event Log I see the following error:
"
Faulting application w3wp.exe, version 6.0.3790.1830, stamp 42435be1,
faulting module kernel32.dll, version 5.2.3790.1830, stamp 424377d2, debug?
0, fault address 0x00015dea.
"
I do get my form for authentication but once authenticated, I never reach
the Folder.aspx page of report manager, instead, I get a "The page cannot be
displayed" ("Cannot find server or DNS Error").
I've tried using Debug Diag on w3wp.exe and here is what I get on the crash
dump report:
"
Thread 15 - System ID 15724
Entry point mscorwks!ThreadpoolMgr::intermediateThreadProc
Create time 14/02/2008 2:50:04 PM
Time spent in user mode 0 Days 0:0:0.171
Time spent in kernel mode 0 Days 0:0:0.125
Function Arg 1 Arg 2 Arg 3 Source
kernel32!RaiseException+53 e06d7363 00000001 00000003
msvcr80!_CxxThrowException+46 019cb508 7a34f188 f64db34c
mscorwks!EEFileLoadException::Throw+119 019cbbe8 0011f338
80070002
mscorwks!AssemblySpec::FindAssemblyFile+307 000fb620 00000001
019cbb10
mscorwks!AppDomain::BindAssemblySpec+19d 019cbbe8 00000001
00000001
mscorwks!AssemblySpec::LoadDomainAssembly+114 0000000b 00000000
00000000
mscorwks!LoadDomainAssembly+144 019ccd20 000f10a8 00000000
mscorwks!TypeName::GetTypeWorker+5fe 019cc6dc 00000000 00000000
mscorwks!TypeName::GetTypeManaged+1ad 019cd82c 7a7223a4 00000000
mscorwks!RuntimeTypeHandle::GetTypeByName+de 00000000 019cd8b4
00000000
mscorlib_ni+2bee29 0230fa60 0230fa60 019cd9a0
System_Web_ni+8fa39 0a2d5614 0a2d5614 02327394
System_Web_ni+94296 00000001 0232824c 01ee2da8
System_Web_ni+9391b 01ee2da8 0231860c 01ee2da8
System_Web_ni+93747 0a2d5614 022d7cec 00000003
System_Web_ni+932fc 023272b4 00000000 02327318
System_Web_ni+931b2 00000000 00000000 022d7ad4
System_Web_ni+930f4 062d2350 022f06d8 022d8f50
System_Web_ni+857e7 00000000 79f481be 00000000
System_Web_ni+83248 00000000 022d7ac8 022d7aac
mscorwks!CallDescrWorker+33 019cdf0c 00000003 019cdff4
mscorwks!CallDescrWorkerWithHandler+a3 019cdf0c 00000003
019cdff4
mscorwks!DispatchCallBody+1e 019cdf00 00000003 019cdff4
mscorwks!DispatchCallDebuggerWrapper+3d 019cdf00 00000003
019cdff4
mscorwks!DispatchCall+b3 019cdf00 00000003 019cdff4
mscorwks!CrossDomainChannel::MarshalAndCall_Wrapper+3f4 019ce040
79f453b8 019ce040
mscorwks!MarshalAndCall_Wrapper2+d 019ce040 019cdee0 79f93fe6
mscorwks!MakeCallWithAppDomainTransition+bc 00000002 79f453e5
019ce040
mscorwks!CrossDomainChannel::MarshalAndCall+64e 019cf524 f64df75c
019cf3bc
mscorwks!CrossDomainChannel::ExecuteCrossDomainCall+7d 019cf524
f64df7e4 019cf54c
mscorwks!CrossDomainChannel::CheckCrossDomainCall+dd 019cf54c
019cf524 f64df038
mscorwks!CTPMethodTable::OnCall+af 019cf54c 000df820 019cf524
0x018c23a5 019cf5b4 022d6554 022e98cc
System_Web_ni+82018 00000000 062d1b48 00000003
System_Web_ni+81c47 00000000 062d1b48 062d18bc
System_Web_ni+81bcd 00000000 062d1b48 062d2188
System_Web_ni+81a76 062d2350 062d22f0 062d0adc
mscorwks!COMToCLRWorkerBody+208 000df820 019cf9cc 019cfa34
mscorwks!COMToCLRWorkerDebuggerWrapper+37 000df820 019cf9cc
019cfa34
mscorwks!COMToCLRWorker+164 000df820 019cfa34 9b96c9d6
0x01a3a295 0000fde9 00000000 019cfce8
webengine!GetAppDomain+154 46c00d97 019cfbe4 019cfae4
webengine!HttpCompletion::ProcessRequestInManagedCode+158 000c1930
00040000 6a2d91a5
webengine!HttpCompletion::ProcessCompletion+3e 01854008 00000000
00000000
webengine!CorThreadPoolWorkitemCallback+18 01854008 77e6bb6d
7a38e228
mscorwks!ThreadpoolMgr::ExecuteWorkRequest+40 000c1930 f64dfaf0
00000000
mscorwks!ThreadpoolMgr::WorkerThreadStart+1f2 00000000 00000000
00000000
mscorwks!ThreadpoolMgr::intermediateThreadProc+49 000c37c0 00000000
00000000
kernel32!BaseThreadStart+34 79f710dd 000c37c0 00000000
In w3wp__PID__11948__Date__02_14_2008__Time_02_50_06PM__702__First chance
exception 0XE06D7363.dmp the assembly instruction at
kernel32!RaiseException+53 in C:\WINDOWS\system32\kernel32.dll from Microsoft
Corporation has caused an unknown exception (0xe06d7363) on thread 15
This exception originated from msvcr80!_CxxThrowException+46.
"
It doesn't feel like the code in my extension is the problem given that it
used to work and I haven't changed anything. Also, it doesn't seem like my
extension is throwing the exception, so it feels more like a configuration
problem somewhere.
Note that if I revert back to the original configuration (without my form
authentication extension), everything goes back to normal, so it really feels
like the problem is in the configuration of the ReportServer/ReportManager
folders.
The server has Windows Server 2003 Service Pack 1, IIS 5.1 and the extension
is coded with .NET 2.0. As specified earlier, I don't think that this
configuration has changed recently. I could show what I changed in the
Reporting Services .config files but first, I want to see if the dump gives
any clue (given that these .config files were working not so long ago).
Any clues or suggestions that I could try?
ThanksHi,
I'm still hoping for an answer. Is this the right place to post an issue
like this?