Send on class (OpenInsight 32-bit)
At 28 AUG 2020 12:44:29PM Jim Vaughan wrote:
Using
Ret_Val = RTI_CDOMail(MailServer,Sender, Recipient, Subject, Body, CC , BCC, ReplyTo, Content, Attachment, MailUsername, MailPassword, UseSSL)
Causes intermittent error "Error at step Sending Unable to invoke method Send on class - Exception has been thrown by the target of an invocation"
Any ideas on what might cause this. Any steps I should take to debug?
Jim R Vaughan
At 29 AUG 2020 03:27PM bshumsky wrote:
Using
Ret_Val = RTI_CDOMail(MailServer,Sender, Recipient, Subject, Body, CC , BCC, ReplyTo, Content, Attachment, MailUsername, MailPassword, UseSSL)
Causes intermittent error "Error at step Sending Unable to invoke method Send on class - Exception has been thrown by the target of an invocation"
Any ideas on what might cause this. Any steps I should take to debug?
Jim R Vaughan
Hi, Jim. Was this always working before, and just started experiencing this problem? Or is this new functionality, and you don't have a "history" of it working correctly before?
What type of system is this running on? Are you seeing the problem on one workstation, or on multiple workstations? Is it a Terminal Server solution, or everyone just running on a local network, or just a single machine that's acting as both server and workstation?
Thanks,
- Bryan Shumsky
At 29 AUG 2020 03:43PM Jim Vaughan wrote:
It's been working for months.
Two issues have recently cropped up.
(1) Problem with BRW not finding a default printer even though a default printer exists, see prior post.
(2) This issue with sending email.
Both are intermittent.
One thing that did change is they started using Office 365 for email.
OI is running on a server, via remote desktop. However, we have also tried running on a laptop, the user has not seen the printer issue on the laptop, he has seen the send mail issue.
Jim R Vaughan
At 30 AUG 2020 05:25PM bshumsky wrote:
Hi, Jim. The type of error you're seeing tells us that we're communicating with the mail "object" in .net (fyi, we're using system.net.mail.smtp) but that when it gets to actually sending it out, it's failing. The fact that it's not happening all the time, but only occasionally, means it's probably not an issue with the wrong port number or wrong username/password, or a problem with the mail server letting you send from that machine (I'm assuming you're always using the same username/password for your connection to the mail server, right?).
So this implies either a problem with antivirus or a firewall blocking the connection to the mail server, or a network issue, or a problem in the mail server itself (Outlook 365).
Unfortunately, I don't think the OI routine is capturing what's called the "inner exception" which could tell us more exactly what's going on. I'll see if there's any way to modify the code to get that, since it could point you more definitively in the proper direction.
- Bryan Shumsky
At 09 SEP 2020 11:06AM Jim Vaughan wrote:
Any ideas on what I should try to try and debug these two issues.
Jim R Vaughan
At 09 SEP 2020 03:35PM Jim Vaughan wrote:
Same company on a different machine, is now getting following error when sending an email.
"Error at create No control specified"
Any ideas?
Jim R Vaughan
At 09 SEP 2020 07:27PM Gerry Van Niekerk wrote:
Hi JIm
when we get this error we normally check the dotnet setup first
ie redo it
if it still isn't fixed then its a username password issue
also when you set you mail server make sure the settings are correct
ie some have :485 or :587 behind it for sending
and the providers would quite often change things without letting anyone know
hope it helps
btw office365
is smtp.office365.com:587 from memory
Gerry
At 09 SEP 2020 07:53PM Richard Bright wrote:
<smtp.office365.com:587 >
Is correct if going direct to the exchange-on-line server.
Note: Today (10 Sep 2020) Microsoft posted to Office365/Outlook users that 3% or more of users were experiencing disconnect errors in attempts to connect to the exchange-on-line server. They were working on the issue. So… the problem "might" possibly be their end. You could try an alternative smtp relay - see Jared Bratu's blog.
I put together a little shell program - easy to do - that can be called from System_Monitor command line for testing the RTI_CDOMAIL using several alternative targets ie gmail, office365 etc and testing attachments etc. Something like that helped sort out issues because it stripped away some of the complexities of custom programs.
Richard
At 10 SEP 2020 02:29PM Jim Vaughan wrote:
Richard,
I have can read his blog but can't see to find a post regarding smtp relay. Do you have a link to the post?
Jim R Vaughan
At 10 SEP 2020 02:31PM Jim Vaughan wrote:
Gerry,
I bet the .net install is the problem. This was a new install to troubleshoot the problem. I bet they didn't install .net.
Thank you let me check.
Jim R Vaughan
At 10 SEP 2020 02:39PM Donald Bakke wrote:
Richard,
I have can read his blog but can't see to find a post regarding smtp relay. Do you have a link to the post?
Jim R Vaughan
Jim, I think Richard is referring to this article:
At 10 SEP 2020 02:57PM Jim Vaughan wrote:
Don,
Thank you.
Jim R Vaughan
At 10 SEP 2020 03:46PM Jim Vaughan wrote:
With regard to .NET.
I just had the user re-run ClientSetup.exe, it did not prompt to install .NET does this mean the correct version is already installed?
Jim R Vaughan
At 10 SEP 2020 04:15PM Gerry Van Niekerk wrote:
No it doesn’t
You can run it from the client setup folder on its own
Gerry
At 10 SEP 2020 04:26PM Jim Vaughan wrote:
Which executable installs .net 3.5?
Jim R Vaughan
At 10 SEP 2020 04:28PM bob carten wrote:
Windows programs and settings, Add windows features, .Net 3.5
At 10 SEP 2020 04:34PM Jim Vaughan wrote:
That shows .Net 3.5 installed.
Two sub-items below HTTP activation and Non-HTTP activation are not installed.
Jim R Vaughan
At 11 SEP 2020 12:31PM Jim Vaughan wrote:
Any other ideas anyone?
Jim R Vaughan
At 11 SEP 2020 02:27PM D Harmacek wrote:
I use the RTI_CDOMail routines every day and don't encounter that issue. OI 9.4
Here is my standard call with a 1 second delay and a yield() following the transmission. Maybe that will help you if you haven't tried this?
foo = Set_Status(0)
retval = RTI_CODMail( all the same arguments as you)
ErrCode = Get_Status(ErrorCodes)
call delayex( 1)
call yield()
Where delayex is a function with a delay seconds as the argument. A replacement of delay().
call sleepery( seconds * 1000) ;* sleepery is in milliseconds
Dave Harmacek - Harmacek Database Systems - near Boston, MA USA
At 11 SEP 2020 02:29PM Richard Bright wrote:
So…. have you tried out the suggested Mail Gun smtp relay or something similar? As I noted - the problem may not necessarily be at the OpenInsight end but the target of Office365 - Microsoft reported sporadic issues of connect failure - don't know if resolved. Testing against a reliable target at least will help you focus on the source of the issue.
Richard
At 11 SEP 2020 02:52PM Jim Vaughan wrote:
Dave,
I will try adding a delay and a yield, maybe that will help.
Richard,
Now I have not tried that yet. I'm not sure if the customer will be willing to use a different email server.
Jim R Vaughan
At 11 SEP 2020 05:58PM Richard Bright wrote:
Hi Jim
<I'm not sure if the customer will be willing to use a different email server.>
The Mail Gun thing (or any similar) is not a replacement for - say Office365 - but rather a smtp relay - which might pass on to office365 or directly to end email server. With such a relay you might be able to verify the successful transmission ex OpenInsight and have a basis to say the problem lies elsewhere. Once upon a time we could run an IIS / smtp relay off our local server. With such setup it was possible to step around passwords and authentication hurdles. Now, typically that infrastructure has been stripped out - and we push out email direct to Office365 or gmail (or other provider).
I think Dave's suggestion of adding a delay using sleepery is well worth a bash - might cover the situation where target email server has latency or indigestion problem.
Cheers Richard
At 11 SEP 2020 06:04PM Donald Bakke wrote:
Jim - If you want to try to isolate the problem further, you can try the SRP Mail Utility. It will work out of the box without a license, but all emails will be flagged with an evaluation message. Since you are only using it to test different things, that shouldn't be a problem. If it works, then you may very well have a problem within OpenInsight. If it doesn't work, then this confirms that the problem is external.