8 Replies Latest reply on Jul 10, 2020 2:13 PM by Glen Conway

    This still does not appear to work in Windows...

    user12248089

      Y:\Oracle\sqlcl-19.4.0.354.0937\sqlcl>echo %JAVA_HOME%                                                                       

      Y:\Oracle\Java\Java8\64-bit\jre                                                                                              

       

      Y:\Oracle\sqlcl-19.4.0.354.0937\sqlcl>path                                                                                   

      PATH=Y:\Oracle\Java\Java8\64-bit\jre\bin;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\     

       

      Y:\Oracle\sqlcl-19.4.0.354.0937\sqlcl>java -version                                                                          

      java version "1.8.0_221"                                                                                                     

      Java(TM) SE Runtime Environment (build 1.8.0_221-b11)                                                                        

      Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)                                                                                                                           

                                                                                                                                   

      Y:\Oracle\sqlcl-19.4.0.354.0937\sqlcl>cd bin                                                                                 

      Y:\Oracle\sqlcl-19.4.0.354.0937\sqlcl\bin>sql.exe                                                                            

      This application requires a Java Runtime Environment 1.8.0_150                                                               

       

      I have an older version of Java 8 'installed' to support some legacy applications but why can't this product just work out the box using the shell environment - it must be reading the Windows Registry? This is Windows 10.

        • 1. Re: This still does not appear to work in Windows...
          Glen Conway

          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.

          and

          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!

          • 2. Re: This still does not appear to work in Windows...
            user12248089

            Thank you Glen. I appreciate the help. I got it working by adding the ..\jdk\jre folder

            Regards

            Graeme

            • 3. Re: This still does not appear to work in Windows...
              user832387

              Hi,

               

              I ran into same issue with sqlcl 20.2

              After following other solutions that were provided, I got little further but can't connect to database using TNS.

              (I can connect using EZConnect though )

               

              I created a bat file to launch the sqlCl. Output attached.

              sqlCLError.JPG

              • 4. Re: This still does not appear to work in Windows...
                Glen Conway

                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.

                • 5. Re: This still does not appear to work in Windows...
                  user832387

                  show tns

                  sqlCLError_TNS.JPG

                  tnsping within sqlCl also works but connect doesn't work

                  sqlCLError_TNSPing.JPG

                   

                  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)

                  • 6. Re: This still does not appear to work in Windows...
                    Glen Conway

                    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.

                     

                    Cheers

                     

                    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"

                    • 7. Re: This still does not appear to work in Windows...
                      user832387

                      >> 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

                      sqldev_tns.png

                      sqldev.png

                      • 8. Re: This still does not appear to work in Windows...
                        Glen Conway

                        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!

                         

                        Edit:

                         

                        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_19.0.0.0.0_LINUX.X64_190404

                        2) 20.2's ojdbc8.jar contains a manifest file showing a 19.3.0 implementation from version label JAVAVM_19.3.0.0.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.

                         

                        Cheers