Take a minute to read through a couple of prior discussions:
Re: Java limitation:lower versions of SQLCL available? -- This describes some general rules for how SQLcl finds the JRE under Windows and Linux.
Re: unable to launch SQLCL 18.1 -- This notes especially how one of the rules changed between 17.4 and 18.1, making sql.exe consistent with sqldeveloper.exe
Hope this helps!
Thank you Glen. I appreciate the help. I got it working by adding the ..\jdk\jre folder
Note that, within a SQLcl session, you can run "show tns" to list out the lookup locations used by SQLcl and which one is actually used.
tnsping within sqlCl also works but connect doesn't work
Never had this issue with ANY previous versions of sqlCl
Is there any configuration setting to bypass Java version check.
The computer does have Java 1.8.0_201-b09 instead of 1.8.0_221-b11 that's shipped with SQLDeveloper
(Its a work laptop and managed centrally)
The problem here is not the version of Java, but the version of the ojdbc8.jar that ships with SQLcl 20.2 being so far out of step with your Oracle 12.1 client's ocijdbc<N>.dll.
Normally SQLcl will try to make an OCI/Thick JDBC connection, but falls back to a Thin JDBC driver if that does not work. In your case, however, I suspect the TNS descriptors may contain some advanced feature that actually requires the Thick driver, so falling back to the Thin also fails, perhaps with a not-so-helpful error message.
What to do? Either:
1) Revert back to a prior SQLcl version which ships with a ojdbc8.jar that plays well with the Oracle 12.1 client.
2) Install an Oracle 19.x Instant Client, and configure the bat script that starts up SQLcl 20.2 to use it (put it as the first step on the PATH environment variable).
Not sure which of those options is easier / possible in your centrally managed work environment.
Edit: There are also the "show jdbc" and "show connection" commands that help you see what is going on in SQLcl, just as with "show tns"
>> What to do? Either:
>> 1) Revert back to a prior SQLcl version which ships with a ojdbc8.jar that plays well with the Oracle 12.1 client.
Will keep using 19.4
>> 2) Install an Oracle 19.x Instant Client, and configure the bat script that starts up SQLcl 20.2 to use it (put it as the first step on the PATH environment variable).
I found out that 19c client will be rolled out over next few weeks followed by DB upgrades
Interestingly, SQLDeveloper 20.2 has no issue connecting using TNS on same computer
Ha! Well, there's this model in my head about how I believe things should work / do work, but reality can be more complex than a model. Since I do not have perfect information about your environment, there is an element of guesswork in any comments I make. Glad to know you have a way forward!
And here is my best guess to explain why 20.2 works for you while 19.4 does not...
1) 19.4's ojdbc8.jar contains a manifest file showing a 19.3.0 implementation from version label JAVAVM_126.96.36.199.0_LINUX.X64_190404
2) 20.2's ojdbc8.jar contains a manifest file showing a 19.3.0 implementation from version label JAVAVM_188.8.131.52.190416DBRU_LINUX.X64_RELEASE
So perhaps if that older version JDBC driver had a backward compatibility issue with the Oracle 12.1 client, it probably got fixed in the later version.