(01-16-2024, 05:32 PM)rlebeau Wrote:(01-15-2024, 09:55 PM)cpstevenc Wrote: And the 2018 ODBC Drivers... for their 2018 Server Software... Use 1.0.2gz Openssl which appears to be from 2015.
Indy definitely works with OpenSSL 1.0.2 (the last release was 1.0.2u).
(01-15-2024, 09:55 PM)cpstevenc Wrote: I copied IdSSLOpenSSLHeaders.pas to my source folder and edited it. I put "cmrs" in the file name CONSTS. And rename the files accordingly.
I don't think that will work by itself, because one of the OpenSSL DLLs is linked to the other DLL, so you would have to also modify/recompile the affected DLL to update the filename in its linkage.
(01-15-2024, 09:55 PM)cpstevenc Wrote: I don't know if this is good or bad... but i had three of our QA testers doing testing for an hour with no errors. Where before , it would crop up in under 1 minute every time.
This is not a good solution. Are you not considering the other solutions I mentioned?
(01-15-2024, 09:55 PM)cpstevenc Wrote: I don't think there is code in IdSSLOpenSSLHeaders to allow me to change the dll file names to look for?
No, they are hard-coded. You can only specify the folder where the DLLs are loaded from.
1.0.2gz causes Delphi 11.3 DataSnap to throw exceptions everywhere on SSL Disconnections ( forget exact message but it is not happy )
As for the side-by-side assemblies, and activation contexts.
I am still trying to wrap my head around those. And how that works and if does what I need. As at time I read your post, I had done my DLL renaming process, which in my screen shot in my previous post, shows both sets DLL's loaded.. my set of DLL's I renamed and my program started... and the DLL's by the ODBC Driver once ODBC work is done and show up... And after nearly 24hrs of testing and "so-far-so-good" I am being told from thousands of tests via Ranorex testing have all passed.
For the ODBC I do nothing special currently... Run A TADOConnection / TADOQuery / TADOStoredproc ... like with any ODBC driver and let it do its thing.
I don't do any code to fire it up / load it up /ect ect ...
Splitting up the code in all our products is a no go. Talking millions and millions of lines of code among multiple programs. To sperate Program from ODBC calls...
Ain't gonna happen. Some of our products are 20+ years old of continuous development and on tens of thousands of workstation systems. And changing how that all works... nope.
I'll keep playing around ... Not trying to be difficult ... just under a time crunch to get this all working in roughly 3 weeks, no matter how hacky in the end, so in a slight "panic mode".... And this doofy ODBC driver is mostly the root of this and the company that makes it don't care to help or budge a finger on it.