Friday, March 23, 2012
Runaway Log Files
runaway log file condition (again).
We had this happen about 2 months ago, prior to SP1, and I reported it here.
MS admitted that had seen the problem, but was not able to reproduce.
In the Event Log, I see thousands of entries like:
Event Type: Warning
Event Source: Schedule and Delivery Processor
Event Category: Logging
Event ID: 123
Date: 8/30/2004
Time: 11:55:16 AM
User: N/A
Computer: KYLE
Description:
The report server failed to write to the trace log.
In the log files, about 8 megabytes in size each until 10 gigabyte disk
capacity was reached, contains repeated entries as follows:
ReportingServicesService!dbcleanup!1308!8/30/2004-11:55:16:: i INFO: Cleaned
0 broken snapshots, 0 chunks
ReportingServicesService!runningjobs!1308!8/30/2004-11:55:16:: i INFO:
Execution Log Entry Expiration timer enabled: Cycle: 50683 seconds
ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO: Expiring
old execution log entries
ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO:
Expiration of old execution log entries is complete. Removed 0 entries.
I was hoping this was fixed in SP1, which we are running now. Any ideas?
thx
JeffI already replied to your other post, but will duplicate info here. We have
found the bug and you should contact PSS for a fix to the issue.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jeff Dillon" <jeff@.removeemergencyreporting.com> wrote in message
news:OYofuMsjEHA.2948@.TK2MSFTNGP11.phx.gbl...
> Our production server ran out of disk space over the weekend due to a
> runaway log file condition (again).
> We had this happen about 2 months ago, prior to SP1, and I reported it
here.
> MS admitted that had seen the problem, but was not able to reproduce.
> In the Event Log, I see thousands of entries like:
> Event Type: Warning
> Event Source: Schedule and Delivery Processor
> Event Category: Logging
> Event ID: 123
> Date: 8/30/2004
> Time: 11:55:16 AM
> User: N/A
> Computer: KYLE
> Description:
> The report server failed to write to the trace log.
> In the log files, about 8 megabytes in size each until 10 gigabyte disk
> capacity was reached, contains repeated entries as follows:
> ReportingServicesService!dbcleanup!1308!8/30/2004-11:55:16:: i INFO:
Cleaned
> 0 broken snapshots, 0 chunks
> ReportingServicesService!runningjobs!1308!8/30/2004-11:55:16:: i INFO:
> Execution Log Entry Expiration timer enabled: Cycle: 50683 seconds
> ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO:
Expiring
> old execution log entries
> ReportingServicesService!dbcleanup!e44!8/30/2004-11:55:16:: i INFO:
> Expiration of old execution log entries is complete. Removed 0 entries.
> I was hoping this was fixed in SP1, which we are running now. Any ideas?
> thx
> Jeff
>
Wednesday, March 21, 2012
Run Subreport according to condition.
Hi all,
in my report, I am using a subreport which takes two parameters and in my main report there is a filed named "ProcessCode".
My problem is that, this subreport should be only run if ProcessCode is 11 oder 29. Otherweise there is no need to run subreport. the column of subreport will be shown as emtpy.
I know, I can return empty string from my stored procedure if the processcode is not 11 or 29, but I would like to learm, is it possible to not render subreport according to condition?
Thanks in advance.
Try to use iif() function for your subreport.
Also, you can setup the condition in the 'visibility' property of the subreport.
Hope it helps,
Shin
|||I'd say that's the answer. Make subreport visible iff processcode = 11 or 29|||that means the query or stored procedure in the subreport will be run in any condition but if processcode is 11 or 29, subreport will be visible, otherwise invisible. its clear...
But I would like to learn, if processcode is not 11, then the subreport should never be render. the stored proc in subreport should not be executed.
otherwise I have same performance problem. the subreport and its query will be run but not will be not visible.
I hope I can explain my point..
Thanks again...