I am very sorry to post a problem for very old version of Team Developer (CTD151 PTF6).
However, the software works just fine with Oracle 9, 10, 11 and we didn't have any problem
of that kind in many years. I hope that somebody can tell us what is wrong and what can be
done to correct the situation.
Setup: on the clean machine we just install Oracle 12c Client 32 and copy the full working directory
with our CTD151 application including SQL.INI. We also set path variable accordingly. We try to coonect to
Oracle 11g Server.
This configuration does not work. The error message:
Code: Select all
5/4/14 11:30:13 1> [connect] dbname = MYDATADB username = someuser
5/4/14 11:30:13 1> [oracon] login string someuser@v2_alias
5/4/14 11:30:18 0> [ERROR] 32560 ORA-12560: TNS: Error by Protocol Adapte
5/4/14 11:30:18 0> r
In Oracle Trace we get:
Code: Select all
2014-05-02 07:36:55.805249 : nlstdipi:entry
2014-05-02 07:36:55.805456 : nlstdipi:exit
2014-05-02 07:36:55.805479 : nigini:entry
2014-05-02 07:36:55.805498 : nigini:Count in the NL global area is now 1
2014-05-02 07:36:55.805514 : nigini:Count in NI gbl area now: 1
2014-05-02 07:36:55.805529 : nrigbi:entry
2014-05-02 07:36:55.805545 : nrigbni:entry
2014-05-02 07:36:55.805825 : nrigbni:Unable to get data from navigation file tnsnav.ora
2014-05-02 07:36:55.805850 : nrigbni:exit
2014-05-02 07:36:55.805865 : nrigbi:exit
2014-05-02 07:36:55.805899 : nigini:exit
2014-05-02 07:36:55.813911 : nigini:entry
2014-05-02 07:36:55.813942 : nigini:Count in the NL global area is now 2
2014-05-02 07:36:55.813953 : nigini:Count in NI gbl area now: 2
2014-05-02 07:36:55.813962 : nigini:exit
2014-05-02 07:36:55.813983 : niqname:Hst is already an NVstring.
2014-05-02 07:36:55.813994 : niqname:Inserting CID.
2014-05-02 07:36:55.814121 : niotns:entry
2014-05-02 07:36:55.814144 : niotns:niotns: setting up interrupt handler...
2014-05-02 07:36:55.814288 : niotns:Not trying to enable dead connection detection.
2014-05-02 07:36:55.814302 : niotns:Calling address: (DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oracleORCL)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=ORCL)(CID=(PROGRAM=C:\Projects\Centura\Application\Login\Login.exe)(HOST=LENOVOVBE)(USER=vbe))))
2014-05-02 07:36:55.814320 : nsgettrans_bystring:entry
2014-05-02 07:36:55.814801 : nlpcaini:entry
2014-05-02 07:36:55.814860 : nlpcaini:prg = oracle
2014-05-02 07:36:55.814873 : nlpcaini:arg[0] = oracleORCL
2014-05-02 07:36:55.814883 : nlpcaini:arg[1] = (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
2014-05-02 07:36:55.814892 : nlpcaini:env[0] = =::=::\
2014-05-02 07:36:55.814900 : nlpcaini:exit
2014-05-02 07:36:55.814945 : ntgettrans:entry
2014-05-02 07:36:55.814957 : ntgettrans:exit
2014-05-02 07:36:55.814972 : nsgettrans_bystring:exit
In Oracle Trace we get:
Code: Select all
2014-05-02 07:15:38.617402 : nlstdipi:entry
2014-05-02 07:15:38.617623 : nlstdipi:exit
2014-05-02 07:15:38.617647 : nigini:entry
2014-05-02 07:15:38.617664 : nigini:Count in the NL global area is now 1
2014-05-02 07:15:38.617679 : nigini:Count in NI gbl area now: 1
2014-05-02 07:15:38.617692 : nrigbi:entry
2014-05-02 07:15:38.617705 : nrigbni:entry
2014-05-02 07:15:38.617993 : nrigbni:Unable to get data from navigation file tnsnav.ora
2014-05-02 07:15:38.618017 : nrigbni:exit
2014-05-02 07:15:38.618032 : nrigbi:exit
2014-05-02 07:15:38.618045 : nigini:exit
2014-05-02 07:15:38.625950 : nigini:entry
2014-05-02 07:15:38.625986 : nigini:Count in the NL global area is now 2
2014-05-02 07:15:38.626003 : nigini:Count in NI gbl area now: 2
2014-05-02 07:15:38.626015 : nigini:exit
2014-05-02 07:15:38.626030 : niqname:Using nnfsn2a() to build connect descriptor for (possibly remote) database.
2014-05-02 07:15:38.626045 : nnfgiinit:entry
2014-05-02 07:15:38.626064 : nncpcin_maybe_init:default name server domain is [root]
2014-05-02 07:15:38.626078 : nnfgiinit:Installing read path
2014-05-02 07:15:38.626091 : nnfgsrsp:entry
2014-05-02 07:15:38.626128 : nnfgsrsp:Obtaining path parameter from names.directory_path or native_names.directory_path
2014-05-02 07:15:38.626141 : nnfgsrdp:entry
2014-05-02 07:15:38.626149 : nnfgsrdp:Setting path:
2014-05-02 07:15:38.626157 : nnfgsrdp:checking element TNSNAMES
2014-05-02 07:15:38.626164 : nnfgsrdp:checking element EZCONNECT
2014-05-02 07:15:38.626172 : nnfgsrdp:Path set
2014-05-02 07:15:38.626179 : nnfun2a:entry
2014-05-02 07:15:38.626188 : nlolgobj:entry
2014-05-02 07:15:38.626196 : nnfgrne:entry
2014-05-02 07:15:38.626204 : nnfgrne:Going though read path adapters
2014-05-02 07:15:38.626211 : nnfgrne:Switching to TNSNAMES adapter
2014-05-02 07:15:38.626219 : nnftboot:entry
2014-05-02 07:15:38.626227 : nlpaxini:entry
2014-05-02 07:15:38.626260 : nlpaxini:exit
2014-05-02 07:36:55.813983 : niqname:Hst is already an NVstring.
It seemes to me, that OCI in Oracle 12c got from SQLORA32 something which it did not expected, although we
see in debug that all necessary variables were set correctly: SqlDatabase, SqlUser, SqlPassword.
Therefore Oracle tries to connect to defualt database ORCL using default protocol BEQ. The real problem is probably
not Protocol Adapter Error, but something else. My suspision is, that connect string sent by SQLORA32 somehow does not meet
requirements of Oracle 12c OCI.
The relevant part of SQL.INI is:
[oragtwy]
remotedbname=MYDATADB,@v2_alias
In ora32.log file we get then
5/4/14 11:30:13 1> [connect] dbname = MYDATADB username = someuser
5/4/14 11:30:13 1> [oracon] login string someuser@v2_alias
Some more information:
Although according to examples in CTD151 documentation the string "remotedbname" should be as above,
we tryed to modify it so that login string in ora32.log will look like a real connect string that can be sent directely to Oracle.
And we have got some interesting behaviour.
If we use
remotedbname=MYDATADB,/somepassword@v2_alias
than we get
5/4/14 11:37:22 1> [connect] dbname = MYDATADB username = someuser
5/4/14 11:37:22 1> [oracon] login string someuser/somepassword@v2_alias
5/4/14 11:37:25 0> [ERROR] 21017 ORA-01017: Username/Password invalid;
5/4/14 11:37:25 0> Login denied
In this case there is a real attempt to connect to Oracle. Oracle Trace also looks the same as when we use this "remotedbname"
in a working configuration with Oracle 11g Client. We cannot get connect in both configurations and both traces are the same.
I suspect that connect failed because it is not allowed to send password as plain string.
One more test
remotedbname=MYDATADB,/@v2_alias
lead to
5/4/14 11:44:18 1> [connect] dbname = MYDATADB username = someuser
5/4/14 11:44:18 1> [oracon] login string someuser/@v2_alias
5/4/14 11:44:22 0> [ERROR] 21005 ORA-01005: No password provided; Login
5/4/14 11:44:22 0> denied
Again, the same message in both working and not working configurations, the same Oracle Traces and we see the real connection
attempt on the Server side.
We suspect that Oracle has changed something in the OCI, so that calls from SQLORA32 to OCI do not contain necessary information
or this information is not properly formated.
Could you tell us what could be the reason for this problem from your point of view? We would think the problem could be the same
with newer versions of TD?
Thank you very much,
Vladimir