Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
SRP_Send_Mail OLE Error
I installed v3 in an OI 9.4 application that I am deploying. This application resides on the same computer as my development copy of OI 9.4. I can send an email from this computer without errors. When testing the deployed application on another computer, I am getting Ole Error - 2147024894. I checked that all of the components have been installed using the Product Documentation on the SRP Wiki site. I then un-installed the installed copy (and all of the Revelation components installed via clientsetup) and then manually copied the folder over where SRP_Send_Mail is working, then ran clientsetup, and I get the same error. Is there something that I am missing?
Comments
It looks like almost none of the RDK installed. I'm not sure why that would be the case, but you can try downloading the RDK here and manually doing an RDKINSTALL on it. SRPMail.chm was a help file, and it doesn't install anymore since all the help is online. I need to update the wiki page to reflect this.
I ran the SRP mail utility install via the *.exe, should we only be installing SRP products via RDK?
TIA.
<32Bit>
2.0.50727.9164
->C:\Windows\Microsoft.NET\Framework\v2.0.50727
4.8.4515.0
->C:\Windows\Microsoft.NET\Framework\v4.0.30319
<64Bit>
2.0.50727.9164
->C:\Windows\Microsoft.NET\Framework64\v2.0.50727
4.8.4515.0
->C:\Windows\Microsoft.NET\Framework64\v4.0.30319
==== Installed .NET Frameworks ====
.NET FW 2.0 SP 2 (CLR 2.0)
.NET FW 3.0 SP 2 (CLR 2.0)
.NET FW 3.5 SP 1 (CLR 2.0)
.NET FW 4.6.2 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.7 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.7.1 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.7.2 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.8 Windows 10 May 2020 Update(CLR 4.0)
==== Installed .NET Core Runtime 64bit ====
No .NET Core x64 Runtime
==== Installed .NET Core Runtime 32bit ====
No .NET Core x86 Runtime
==== Installed .NET Core Sdk 64bit ====
No .NET Core x64 Sdk
==== Installed .NET Core Sdk 32bit ====
No .NET Core x86 Sdk
==== Languages ====
< Installed Languages 3.0>
English - United States
< Installed Languages 3.5.x>
English - United States
< Installed Languages 4.x>
English - United States
==== Updates ====
Microsoft .NET Framework 4 Client Profile
KB2468871
KB2468871v2
KB2478063
KB2533523
KB2544514
KB2600211
KB2600217
Microsoft .NET Framework 4 Extended
KB2468871
KB2468871v2
KB2478063
KB2533523
KB2544514
KB2600211
KB2600217
KB2468871
KB2468871v2
KB2478063
KB2533523
KB2544514
KB2600211
KB2600217
==== END REPORT ====
Yes, some of our installers choke on UNCs, but that's because Windows gets in the way. We recently discovered that using UNC paths within Windows' own DOS Command Prompt can fail for even built-in commands. Our installers can deal with UNC paths no problem when doing other tasks like installing files into a folder and registering OCXs. The problem is specifically when we try to run RDKINSTALL from the installer. This requires spinning up a new invisible process, and it seems certain permissions won't carry over to that process despite the installer's elevated permissions.
It's not that SRP is reticent to support UNC paths. Rather, we haven't found the hoops through which Windows bids us to jump. Admittedly, I haven't put as much effort into troubleshooting this issue as I would like due to my workload and given the fact that there is a work-around, hence the RDK I sent to you.