Michael Kipp (Customer) asked a question.
Hi, I'm upgrading OE 11.7 32-bit with Oracle DataServer on Windows Server 2022 to OE 12.8. After backing up the schema holder files, doing the v11 truncate, v12 proutil conv1112, I can't connect with prowin with the original db connection parameters (.pf file) that worked with v11.7 It gives an error:
Unable to load shared library (14945) ORACLE error -1012 see "ORACLE Error Messages and Codes Manual". (1252) ** Failed to connect to ORACLE database <dbname>. (1451)
I'm using Oracle client 12.1.0.2 (shown as compatible for v12), verified DLC, JAVA_HOME, ORACLE_HOME, PATH env. vars are all set.
Has anyone else gone down this path to shed some light where to look? Did I miss a step?
Sorry if this has been asked and answered - the search box in Progress Community is giving an error so I can't check.
Unable to load shared library often indicates a bit mismatch. Are you sure your DataServer is 32 bit?
Hi Stefan, Thanks so much for your reply - I was flipping between both 32 bit and 64 bit trying to get this to work. I have one server with 64 bit OE studio for performing the v12 truncate and it gives the shared library error, so your answer fits this. However, I have another server with 32 bit Oracle Dataserver and it gives this error to the same truncated schema holder:
ORACLE error - 1012 see ORACLE Error Mesages and Codes Manual. (1252)
** TNS:protocol adapter error
Failed to connect to ORACLE Database ... (1451)
The Oracle 12.1.0.2 client, tnsnames.ora, sqlnet.ora, and connect.pf all remain unchanged from what works with v11.7 on the same server. Tnsping and sqplus with the id/pwd all work fine. I just switch the DLC environment variable and confirm via "WHERE prowin32" that it is running OE12 (32 bit DataServer). Dataserver.log extended logging shows:
-- OCI call OCIHandleAlloc <0>
INTERFACE OCI retr OCIHandleAlloc <0> rc = 0 (2000 us)
-- OCI call OCILogon <0>
INTERFACE OCI retr OCILogon <0> rc = -1 (80000 us)----------
-- OCI call OCIErrorGet <0>
-- error text: ORA-12560: TNS:protocol adapter error ---- (16127)
Am I doing something unusual in trying to upgrade and test the schema holder for a remote Oracle DB, or did v12 change how the connection parameters should be? I was a bit skeptical of now having to use 32bit OE Studio to truncate the schema holder to then work with 32bit Oracle DataServer. My connect.pf syntax is:
-db <unc path to schema holder> -RO
-db <dbname>
-U <OracleUserName>@<dbname>
-P <OracleUserPwd>-c 2000
-ld <dbname>
-Dsrv PRGRS_NATIVE_LOCKWAIT,2
-dslog dataserver.log
-Dsrv qt_debug,EXTENDED
I am assuming that the -c parameter in your pf lost a carriage return when removing the password.
Thanks Stefan. Yes, sharp eyes and correct assumption to spot the missing CR before -c. We use the Dataserver in local mode too. Does it seem perfectly fine and normal with OE v12, or risky that we now need to use 64 bit progress db utilities to prepare a schema holder that is accessed via OE 32 bit legacy application? OE I will try the id/pwd notation, and also creating a new schema holder with a .df. Fingers crossed!
Thanks - Michael
What is really odd is that dataserver.log shows -- ORACLE_SID not set or NULL (14878), which is what I'd expect since the Oracle DB is remote, but SQLNET.LOG shows a generic connection string without any of my connection parameters for db name, username, or password, and instead shows a mysterious BEQ protocol, SID=ORCL, and the username as my windows account:
(DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oracleORCL)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=ORCL)(CID=(PROGRAM=E:\FLS\Progress\OE128\bin\prowin32.exe)(HOST=<my hostname>)(USER=<my Windows Acct>))))
It's like Progress is using some sort of default or failing to pass the parameters properly.
For comparison, here's our login attempt:
Our schema holder does not contain any connection information:
Thanks again! Just to confirm you are using v12 32 bit as well? What is the minimum OE product you have installed for user device (or terminal server) to make this work - just the OE DataServer 32bit, or also client networking 32bit?
No, 11.5 was the last version we supported 32 bit on. x64 only since 2015 (11.6).
Our current supported versions are 12.2 and 12.8 (both x64).
PASOE connects to the schema holder and Oracle database.
prowin or _progres can also be used - I think these just need the DataServer x64 license.
I vaguely recall the MSS DataServer requiring client networking at some point in the dark past.
We have a legacy 3rd party app that needs 32 bit. Installing only OE Oracle DataServer 32 bit does install prowin32.exe and AI searches indicate this is sufficient.
With what my dataserv.lg and sqlnet.log shows (in my 2nd message above), it appears like Progress isn't even using them and ignoring my -U -P altogether, because I can also force a syntax error in, or even rename tnsnames.ora and sqlnet.ora, and it doesn't give any error and shows the same results. I wonder if Progress is over-riding with BEQ mode somehow to not use Oracle Networking, perhaps with registry settings, some other configuration file, or has done this because it's an evaluation license.
I had some partial success. I was able to use Progress OpenEdge v12 64 bit to create a new schema holder, import all the data definitions, and then use that to connect prowin -pf connect.pf to connect through Oracle 19c client to the database and perform a query using Oracle networking (TNSNAMES.ora/SQLNET.ora).
However, on our terminal server trying to connect through Progress OpenEdge v12 32 bit prowin32, using the very same -connect.pf, TNSNames.ora, SQLNET.ora, and with 32 bit Oracle 19c still gives the original tns:protocol error with same output in SQLNET.LOG referencing the mysterious protocol=BEQ and SID=ORCL.