Report Server/Scheduled Reports/Email

When that happens here, I find it's usually an error in the email addresses or the attachment size is larger than the size allowed in dbmail. Caryl

I'm guessing you guys aren't on RAMP? If you are they can certainly help you troubleshoot, otherwise I'd try to start with whatever machine or service is actually queuing your mail. That should give you answers like "never requested" or "file size too big". Maybe dbmail has logs somewhere also? That I don't know. In the past we've had issues with file size, but also with "from" address, in cases where that was cleared by whatever sending service we were using. Lastly, Report Server has always been a little flaky itself. Do you have evidence that the reports are being run as scheduled?

No, not on RAMP. I will check with IT about checking the logs. We do have evidence of the reports running as they are visible in Tools>View Reports, they just never emailed out. These are not new reports, and have sent in the past. Other emailed reports did send on the same days that these did not. All the email addresses are correct, but no one in the To on each report received them. As for file size, the one report is only 1 page long and as I mentioned has sent every day that it's been scheduled. Also of note is that this did not happen on the same day for these two different reports to not send. And yes, flaky is a 'nice' way of describing the report server...

Aileen, In that case, it would be all emailed reports, not just random ones.

We had a problem similar to this recently: we narrowed it down to the fact that the reports failing to send were going to different email addresses than the ones that succeeded. We then reviewed this with RAMP and determined that they had received some bounces from the mail service here on campus for those addresses, and had in turn blocked them.

Hi Michelle, Try not to schedule multiple reports at the same time or very close to each other, especially if they require long run times. This was RAMP's recommendation to us. I hope this helps! Ahmet Unal, IS Manager UMSL/Touhill PAC

Ahmet, Yes, we have always made sure to schedule them enough apart and these are reports we've had scheduled for quite a while that just didn't send.

I believe Gawain mentioned this also. Is it possible that your e-mail service provider suppressed the e-mail addresses of the report recipient for some reason or report recipient's e-mail service provider blacklisted your mail server? The latter happens more often with small service providers without sophisticated spam filters when your e-mail service provider is not duly authorized. We experienced this problem. All recipients received one of our reports, except for one outside client. We used client's personal e-mail address and the report e-mailed successfully. So, the question is whether your problem is with the e-mail address or the scheduled report process.

Hi Michele, On at least two recent occasions, we had an issue where only InfoMaker scheduled reports were not emailing out while SSRS ones were working just fine. A server reboot was ultimately required to get them to work again; at the moment, I'm not sure the cause and was not able to get it working without rebooting the server. Is it possible the two reports that aren't emailing are InfoMaker and the ones that are working are SSRS? If so, you may be experiencing the same issue we ran into. Thanks, David

Thanks David, but that's not it either. Almost all of our scheduled reports are Infomaker.

Ooh...that's an interesting one to keep an eye out for.

Thanks Ahmet, but again I don't think that's it either because no one in the email recipients received the email and they are all internal email addresses, but those same people did receive other email reports in the same day.

I think we may have figured out how it's happening but not how to fix it... The report server, immediately after creating the file attempts to email the report and fails (thinking the file does not exist) due to some kind of millisecond time lag on the shared network storage. Perhaps because the shared storage is busy with the other load and is just not showing the pdf in the file directory fast enough. Does anyone know if there are settings we can alter to set a lag between creating the report file and attempt to email?

David, Gawain: IIRC, I've had Infomaker reports fail to email even though SSRS was working fine due to the Windows Print Spooler service having quit! Infomaker reports don't have native PDF export, so they use Ghostscript which relies on a virtual printer. (Fun Fact: the next version of PowerBuilder will have PDF generation built in! No idea if Tessitura is planning to update, though.)

As for random IM reports failing to email, I would really expect to see something in the logs; either the logfiles or the email log tables. But one thing you might want to check is that your Report Server concurrency is set to 1 (this is configured in the report server itself, or its ini file). Any other value makes it untrustworthy IMO -- I've had simultaneous schedules get their report attachments switched. That might be another thing to check -- are the reports that are failing to email scheduled at the same time as other schedules, or are they all spread out?

OOH OOH I KNOW THIS!

(Sorry, I didn't see your post about schedule timings before my last reply.)

I think I had the same problem once about storage lag and timeouts. It's a T_DEFAULTS setting: EMAIL_REPORT_FILE_TIMEOUT. I have mine set to 10 (seconds).

---

P.S. Here's a thread about the Report Server.
P.P.S. Join us in Slack! Info: https://tessituracoders.bitbucket.io/