This is an Oracle database error, indicating that the Designer client was not able to connect to the database. Are you able to connect to the same database using SQL*Plus installed in the same ORACLE home as Designer?
Simply restarting the service doesn't help - same behaviour to me once in two weeks.
The only thing that works is restarting the machine. Check if you use NTS authentication.
Could be that you have problems with the domain controller/active directory that
can cause in such authentication failures.
Just to workaround this problem (in the case of this authentication method) you
can create a local os user, add him to ORA_DBA group and start your oracle
client in the context of this local user ("runas").
No other idea to solve this problem. I'm sure when the system is well configured,
then there is one process which has lost communication with the authentication
I'm no Oracle expert, but from what can make out the NTS option makes the Oracle client attempt to use your current Windows domain credentials to authenticate you with the Oracle server. This could fail for a couple of reasons:
- The Oracle server is not configured to support Windows authentication
- The credentials you use to login to your local machine are not sufficient to allow you to login to the server.
In my case, it was the later. Despite the fact that I had told the client to use a different user name and password, it was still attempting to login using my domain credentials first. This failed because I was logged on to my local machine using my normal domain credentials rather than my administrator account.
Replacing the line:
in sqlnet.ora resolved the issue by disabling local support for authenticating using Windows credentials.
Here is something really strange. I had the same problem so I changed the file specifying NONE but this gave me a different credential error so I changed the file back to NTS. I resaved the file, rebooted the box and voila everything started working OK.
I had this problem on 3 other servers (we are running SAP) and on everyone of these servers I merely added a comment line to the file, rebooted and it fixed every system.
It would be nice to know what causes this problem to all of a sudden pop up when these databases have been running for several months without any similar issues.
I have had a similar problem. And the solution worked well too. I am slighly curious to know more on what would this mean.
"The consequence is that it's no more possible to connect as sysdba without password. The following statement return the error ORA-01031:
connect / as sysdba "
Does this also mean that it would not be possible to connect to the database from a remote machine in anyway?
Reasons why would you not keep it SQLNET.AUTHENTICATION_SERVICES= (NONE) or
I repeatedly see the solution to the ora-12638 error as changing your sqlnet.ora file to remove NTS authentication mode, however, what happens when you have some databases which ARE set up for OS (windows) authentication?
A client has one sqlnet.ora. Our standard is to set that up as SQLNET.AUTHENTICATION_SERVICES= (NTS). In this way, we had hoped that when a userid/password was provided, Oracle would use it.... and when OS authentication was appropriate, Oracle would use that. This works 97 percent of the time, however, the 3 percent kills us.
Oracle seems to go the OS authentication route even though an oracle id and password is supplied. Why is this?