I'm currently on Toad 13.0, but when I connect to a database where the server itself is down, Toad, tnsping and SQL*Plus all take the same couple of seconds to report back that there is no listener. (ORA-12541: TNS:no listener)
When the listener is up and running, but the database itself is down, then Toad, tnsping and SQL*Plus all take the same couple of seconds to report the ORA-12514: TNS:listener does not currently know of service requested in connect error.
I'm using Oracle "fat" client and not LDAP, EZConnect, or Direct etc - I have a full install of Oracle XE 18c for Windows on my desktop, and I use that client for everything I connect to oracle-wise. All my connections are configured in Toad to use the tnsnames naming methods to connect. My tnsnames.ora file lives within the XE 18c installation, and I have a TNS_ADMIN environment variable defined that points to it.
In summary then, I can't reproduce your problem on my setup here, sorry.
Then tried connecting, and the behaviour is the same, it took nearly a minute. While just testing the connection, it took me ~2 seconds.
FYI: Toad is installed in terminal server, where there is no access to public internet (access is only to company intranet).
By the way, this topic is quite similar to my problem, since this same thing happens when database instance is up and running, but I have put wrong username/password:
Is this repeatable? Does it happen every time the instance is down?
As I cannot reproduce it here, it might be the terminal server that's causing it. When you test, what do you use? Tnsping? SQL*Plus? Are they in the terminal server environment or running locally from your desktop/laptop? (Are we comparing apples with apples!)
I encourage you to look my last post also, as I edited it a few minutes back. So problem is the same, when I use wrong username/password to connect to database instance, which is up and running.
I bet this other topic has the same issue, since in my case, it is about right, it takes me 40-45 seconds to report the error also.
And yes, it is repeatable always.
I do not use tnsping nor the sqlplus to test the connections.
When I test, I use Toad functionality also (Session -> New Connection -> (select connection) --> Test Connections).
I just let some of our developers test it. They have Toad installed in their localhost, which has access to public internet. And he got error in 2 seconds.
Bear in mind, when this ORA-12514 or ORA-01017 is produced, it will produce the following pop-up:
Could it be possible, that it is already trying to resolve the following internet addresses (knowledge base, forum) in the background..?
thanks for the explanation regarding how you test. I wasn't certain how you were testing.
I've connected to a database here and then shut it down (I have the power!) and then, on session->test Connection, I get the following window in about a second:
I do not get any attempted connections to the internet to check the KB or the Forums unless, I click the button shown.
However, it sounds, from your latest posting, that your colleagues with direct access to Toad don't have the same problem that you are suffering from - so they appear to be seeing what I see - a quick response. his would tend to pint the finger at the Terminal Server as the potential culprit.
I checked the various Toad Options and there doesn't appear to be one that determines whether to automatically search the internet for error details or KB advice.
It appears from John's updates on your other problem, that you are suffering from a bug in 10g when the user's account has expired and you cannot connect to change the password.
It appears from John's updates on your other problem, that you are suffering from a bug in 10g when the user's account has expired and you cannot connect to change the password.
No, this is no way connected to that topic. Username is not expired, and I tried the same with 10g, 11g, and 12c databases, and behavior is the same, it takes ~40-45 seconds to report error:
When connecting with wrong username/password
Or when connecting to database instance, that is not up and running (server itself is up and running)
I don't think that problem is terminal servers. My bet is, Toad is trying to connect to somewhere in background.
In firewall log, I get policy violation to this IP address (152.195.132.183 HTTP), when connecting with wrong username/password or instance that is down.
And when I click to these links from that pop-up, each time it is trying to resolve the same IP address.
Sorry, what I meant was, your other problem was cause, it appears, by a 10g bug. Not that this problem was caused by the same bug. Apologies for my English - I'm Scottish!
When my "test connection" fails, I click the link and it takes me to support.quest.com which is a completely different (set of) IP address (es) - 13.35.198 followed by one of .83 or .87 or .114 or .127, and nothing like the one you are seeing.
Do you have a proxy server between you and the database or outside world? Can you ping that IP address (I suspect not, I certainly cannot from here, but our internet is heavily proxy'd and there are many addresses we have no access to etc.)
Pinging sa8gl.wpc.mucdn.net [152.195.132.183] with 32 bytes of data:
Reply from 152.195.132.183: bytes=32 time=7ms TTL=53
Reply from 152.195.132.183: bytes=32 time=7ms TTL=53
Reply from 152.195.132.183: bytes=32 time=7ms TTL=53
Reply from 152.195.132.183: bytes=32 time=7ms TTL=53
Ping statistics for 152.195.132.183:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 7ms, Average = 7ms
PS C:\Windows\system32>
Interesting. I don't work for Quest, so I'm not able to say why Toad might want to connect to that address when a session test fails. Sorry. I suspect we need a developer to jump in now.
PATH: C:\Users\AppData\Roaming\Quest Software\Toad for Oracle\13.0\User Files
After the copy process you have to restart TOAD.
At first wrong password attempt, TOAD waits for a while. Then you’ll get a quick response for the wrong password attempts.
Toad's connection error dialog has some links to quest resources, but to make sure those links are up to date, we try to download file from one of Quest's servers. If the PC where Toad is installed does not have internet access, you can prevent Toad from looking.
If you download that online_resources.xml file, and put it in your User Files folder, that may help.
In Toad 13.2, there is a Toad.ini setting you can make which disables all internet-related activity in Toad.
in [SETTINGS]...
InternetAccess=0
But as I mentioned, that works in 13.2 and newer, not 13.1.
Another question though, is it possible to set this somewhere from the settings also, that do not download this file from internet, but take this file from some fileshare location..?
I am asking because, we have lots of users using Toad in terminal server, that would mean, that this file needs to be copied to each user folder separately each time when doing Toad upgrade (with new version of Toad, there comes new User files folder)..?
We don't have a way to get the file from somewhere else, sorry.
However, on upgrade, the User Files folder is copied from the the old version to the new version (to preserve your settings) so the online_resources file should be carried along.
If you are installing from MSI file, you can disable internet access with a command line option from the installer.
search this page for "internet" (it's at the bottom)