Hi
Toad 13.1
I have noticed when instance is down and trying to connect there (direct connection), then it would take nearly a minute to output the following error
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
At the mean time, when I test the connection, then it takes about ~2 seconds to output the same error.
Why is that..?
Regards
Raul
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. 
Cheers,
Norm. [TeamT]
Yes, I am describing the case, where specific database instance is down. Server itself is up and running.
I also tried tnsnames.ora
Set this as follows:
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradb.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
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:
Regards
Raul
Hi Raul,
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!)
Cheers,
Norm. [TeamT]
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).
We have many terminal servers, each of these have the same behaviour (windows server 2008 - windows server 2016).
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..?
Raul
Hi Raul,
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.
Cheers,
Norm. [TeamT]
HI
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:
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.
Raul
Hi Raul,
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! 
That's an interesting IP address, this link - 152.195.132.245 IP Address Detail - IP Address Location Lookup - Abuse IP Report - puts it right in the middle of the Cheney Reservoir in the Cheney National Park!
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.)
Cheers,
Norm. [TeamT]
This still looks to be some quest IP.
Search google: "toad 152.195.132.183"
I get the following hostname: community-downloads.quest.com
And this will ping just fine through hostname on my localhost, that has access to public internet.
ping -a community-downloads.quest.com
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=53Ping 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>
PS C:\Windows\system32> nslookup community-downloads.quest.com
Server: YYYYYY.domain....
Address: XXXXXXNon-authoritative answer:
Name: sa8gl.wpc.mucdn.net
Address: 152.195.132.183
Aliases: community-downloads.quest.com
community-downloads-quest-com.azureedge.net
community-downloads-quest-com.ec.azureedge.net
scdn1.wpc.6c216.mucdn.net
Raul
Hi Raul,
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.
Cheers,
Norm. [TeamT]
I agree. Will these developers also read these forum posts, or do we need to make another topic somewhere..?
Raul
Hi Raul,
no, the developers practically live on these forums, so they will pick this up as soon as they get a moment. There's no need to start a new topic.
I'm not sure which time zone they are in, or when their day begins, but they will be here.
Cheers,
Norm. [TeamT]
Ok thanks.
Let's hope they'll pick it up some time then..
Raul
Oh, I was blind.
This other topic, had solution:
We’ve just solved the problem by copying following .xml file to the following path indicated below.
XML FILE : http://community-downloads.quest.com/toadsoft/ORACLE/VERSION/online_resources.xml
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.
Yeah, this online_resources.xml file fixes this.
For Toad 13.2, this is not yet released, correct..? (since from support.quest.com the latest seems to be 13.1.1)
Raul
13.2 is currently in beta. If you are interested, you can download it here:
The 13.2 beta requires that 13.1 is installed.
Ok..
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)..?
Raul
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)
