Hi everyone,
Since our v15 upgrade a handful of scheduled reports have been consistently failing to send, and the only error they display in the View Reports screen is 'Error sending email for request Id 'XXXXXX' The report itself runs fine and can be viewed within the application, but the email functionality is failing.
Does anyone have any insight or breadcrumbs as to what causes this problem, or what this error actually means? I've seen reports fail to send but then fix themselves a few days later, or in other cases building an identical copy of the schedule to an identical recipient list works fine for some reason. I'd love to get any sort of lead on how to resolve, or pinpoint whether there's any local email environment issues at play (we're on RAMP).
Thanks!
We haven't been able to send emails of scheduled reports either, so I'm interested in this as well. In fact scheduled reports would not run at all. After some investigation with Tessitura support, I finally changed the Local_Library_List in T_DEFAULTS from:T:\userreports\userreports.pbl,T:\userreports\nscan.pblto:\\admiral\tessitura\userreports\userreports.pbl,\\admiral\tessitura\userreports\nscan.pbl
They work now, but why? We've had the T: drive mapping in that setting for years. And now v15 doesn't like it.
What do you all have for your Local_Library_List in T_DEFAULTS? Drive mapping? Or unc path?
David Vivino (Past Member)
I'm on RAMP so my experience may be different. I have UNC paths...
\\kriostess\pub\XXXX\Live\User Reports\lsccustomreports.pbl,\\kriostess\pub\XXXX\Live\User Reports\performance_copy.pbl,\\kriostess\pub\XXXX\Live\User Reports\entitlements.pbl
where XXXX is my 4 digit RAMP site code.
This is a symptom of moving the Report Server duties to the Tessitura Processing Service, which is finally a windows service. Historically, sites would set up a single shared network location for custom Infomaker libraries so changes made to custom datawindows/reports could be deployed with a single update. This can still be achieved using UNC, instead of a mapped drive. Mapped network drives are not recommended for use with a windows service for several reasons, some of which are outlined here:
https://docs.microsoft.com/en-us/windows/desktop/services/services-and-redirected-drives
Because the LOCAL_LIBRARY_LIST setting in T_DEFAULTS is used both by TPS and the client desktop application, we can no longer officially support mapped network drives. The easy workaround is to swap out a mapped network drive for a UNC file path in this setting. This is what RAMP uses (as Tom attests to) and addresses the issues mapped drives brings.
We are updating the help system and documentation in T_DEFAULTS to note this change.
Best,
Ryan