Have a really strange issue going on. Some of my scheduled BAQ reports also print when they shouldn’t. These should strictly be going out as an email. There is no breaking\routing setup for any of them in the report styles. The only way I have found to fix it is to go into system agent, delete the task and recreate it… and hope it works. Sometimes I have to do this more than once, testing after scheduling, until it works as it should. There’s no rhyme or reason to it. Has anyone else experienced something like this and is there an easier way to fix it?
I have a similar (but not exactly the same) issue with scheduled emailed reports. Mine aren’t break routing either. If I run a report and choose to email it (instead of printing or previewing), and select a recurring schedule, the email goes out fine. But the next time I launch the client, I’m presented with a “Save As…” dialog box to save the PDF that was created for the report. To be clear the “Save As …” window doesn’t appear until after the scheduled time (usually at midnight, and with no client open).
Maybe it has to do with the client’s default printer. Like I’m getting the "Save As… " dialog because my workstation has a PDF printer as it’s default printer. If mine had a regular printer, it would probably just get sent right to the printer.
Here’s my original post on it:
I’ve been coming to the conclusion that email is the UDP of file transfer.
We need a better strategy to manage its fragility.
Add a checkbox in the email settings dialog, like:
One thing I failed to mention. This only happens in my Test environment!
The very first thing I do when I setup an email account is to turn off read receipts.
I also generally read the text-based versions of emails for privacy/security reasons so web beacons won’t work either.
1 Like
Whew… that’s a dangerous checkbox. Someone somewhere hates you, I’ll guarantee it. As someone that doesn’t use read receipts, this would piss me off haha.
2 Likes
I just did a test (in my test environment), emailing a simple built-in report to myself, after changing the default printer on my workstation, and got:
Looking at the Reports tab in the System Monitor shows the report was "Created On: 9:19:05 AM. And has a “Last Action On” of 9:19:34 AM
The headers in the email I received say it was received by our exchange server at 14:19:05.8654 (the 14 to 9 is the timezone diff).
9:19:04 - Report rendered (that’s the time shown on PDF that was emailed)
9:19:05 - Report was created on the App server (per Sys Monitor)
9:19:05.9 - Email received by Exchange from App server IP (per email headers)
9:19:34 - Last Activity Date (per Sys Monitor)
I bet If I had closed my client right after submitting, the email would go though, but the failed print message would n’t show until the next time I launched the client, which launches Sys Monitor.
Just as I thought. The attempt to send the report to the print happens when the Sys Mon is loaded (for the specific user).
- I submitted a report to email and exited the client immediately.
- Waited until I received the email
- Launched the client as a different E10 user. No attempt to print occured.
- Sys Mon set to show all task
- Sysmon shows this email and the previous email both completed
- The Reports tab only shows the prior email (the one that tried to print)
- Closed E10 client and re-launched as user that submitted email. A few seconds after the Sys Mon loaded, the Print Error notification appeared:
- Opening Sys Monitor shows the last activity of the 2nd email to be right when Sys Monitor was launched for this user.
I only seem to get this when using the email “destination” when printing.
Break Routing with an email widget seems unaffected.
1 Like
Yeah, that seems to be the same issue I’m having. What gets me is that this doesn’t always happen. When it does happen, I can usually recreate the task and the problem vanishes. I have no clue what’s causing this issue to appear sometimes, but not always.
In my test environment, it happens nearly 100% of the time. But then again, I’m the only user in it.
This was suggestion made before the Ideas site was launched but report creation should be separated out from distribution. We’re implementing 365 and when there is an error in SMTP, the report might be gone (depending on your Archive time).
I would separate the report creation and the notification:
Create the report and store it in a repository (DocStar, SP Document Library, …)
Now users can subscribe to the repository to be notified the way they want: an email with link, an email with attachment (
), a message in a Slack or Teams channel, a text, whatever. It makes a supplier/customer portal possible which would reduce those calls asking, “would you please resend that?”.
1 Like