• Replies 14 replies
  • Subscribers 337 subscribers
  • Views 520 views
  • Users 0 members are here
Related

v15+ TPS scheduled reports - ambiguous 'Error sending email' message

Evan Cartwright
$organization

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!

Parents
  • $organization

    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.pbl
    to:
    \\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?

  • $organization in reply to David Vivino (Past Member)

    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

Reply
  • $organization in reply to David Vivino (Past Member)

    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

Children
No Data