...8i Client was too old ?
Yes- *might* be able to tell an 11g database server (XE? 184.108.40.206?) to accept older client versions but Net8 is very old. Suggest at least 11gR2 client for the remote connections.
Possibly, at the database server sqlnet.ora file add:
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
Another thought, might be the x64 architecture in ODBC- lots of info re:Windows ODBC and the x64 version. The ODBC applet for x86 is still there in Win10, try running %systemdrive%\Windows\SysWoW64\Odbcad32.exe and see if the DSNs show.
If the ODBC setup is via the x64 version, don't think it will see the DSNs set up in the ODBC 32 bit. Maybe. Don't have ODBC on the current desktop or a server with any version 8 oracle clients to try and verify.
Many thanks for your response, we are running Oracle 10 that on a Windows Server.
For your mentions x64 issue, we have setup the oracle 8i client on Windows 7 32 Bit, and after upgraded to Windows 10 32 Bit, all these configuration files are still there...
So, I am thinking.....
1) Is there some where Win10 will ignore my Win7's oracle setting and caused my Win10 dont know where the oracle server to be connect.....?
2) If related to the version too old, can I simple update the oracle client application only (because configuration files still there..) to make it works ..?
Many thanks and have a nice weekend
Well, since trouble started with Win10 verifying that client setups behave as they should, eg. at the database server via sqlplus check:
- connect /as sysdba
- connect <user> --bequeath: %ORACLE_SID% env var (or registry settings)
- connect <user>@(DESCRIPTION=... -- full connect string with HOST=...PORT=...SID|SERVICE_NAME... beware typos
- connect <user>@alias -- tnsnames.ora ALIAS = ...host=...port=...
Only the last two will work from a remote client. One possibility is the OS change may have added a firewall port block on the db server host, but the usual symptom for that is a "tns-12541 no listener..." error, getting the 12560 reveals that it probably is reaching a listener but there's something not right with either the listener or the client setup.
And make sure the instance has registered with the listener, cmd.exe lsnrctl stat and lsnrctl serv that should show the endpoints (hostname or IPv4 address) the listener is using and the service name(s) for the instance. If IPv6 is in the mix, the host= value has to be a valid hostname, listener.ora won't like an IPv6 address.
Thanks for your help and to study my case few weeks ago, my Win10 (17134) issue finally got workaround by following method. after copying the application and run locally instead of UNC shared location, error message disappeared.
have a nice weekend ! Thanks !
ORA-12560 with UNC use after Windows 10 version 1803 upgrade
Last updated on MAY 16, 2018
Thx, appreciate the update. My WinDoze10 laptop is courtesy of The Boss- lots of domain policy lock downs, and Best Ever (boo!) no local admin group membership.
Have to go to the Home Office to play with Win7pro, that's my only option. No Win10. (yay )
UNC shared location, error message
Ouch- have seen strange, reliably unreliable issues when depending on UNCs. Seems that most hosts don't mind randomly closing the resource(s) needed to get to UNC objects.
And most times, just prior to the app needing them, error, boooo. Or should I say *boom*.