I'm using SSH tunneling to connect from a Windows 7 machine to a remote Postgres database.
The tunnel works fine when I use pgAdmin to connect to the remote database. However, I haven't managed to set up an ODBC DSN to connect to the remote database.
I'm creating a System DSN with the same server address/username/password/port/ssl mode as pgAdmin but when I click "Test" I get: "Could not connect to server; No connection could be made because the target machine actively refused it."
Any ideas on where to start debugging? I've ruled out Windows Firewall and remote server configuration, since I can connect with the exact same information in pgAdmin.
Edit
The problem resolved itself after reinstalling Windows.
When debugging this the first thing to do is to start testing the PostgreSQL server with the psql command line utility. This avoids issues of drivers etc to see what is actually going on. Generally speaking my troubleshooting process is:
Can I ping the server?
Can I connect with psql?
When I test my connection via the control panel, does it work?
Now, assuming the problem is on #2, the first thing I would do is try disabling firewalls on both sides (they can be brought up and tuned after trying with both down). This rules out misbehaving firewalls and if it shows this to be a problem then you have the answer on where to troubleshoot.
In my experience Windows firewall can cause all manner of problems. I have even seen it block web pages halfway through the web page. I don't think you can rule out Windows Firewall based on the information you have provided.
If this happens again, the first things to do include disabling both any antivirus software and firewalls.
The other possibility would be a bad ODBC config (maybe port 5423 instead of 5432) or a badly installed DLL of some sort. The latter may be fixed (or not) using sfc /scannow or reinstalling the odbc driver, or other actions.
Related
I have a windows 16 machine on AWS. I installed Cygwin on it so that I can connect it as a jenkins slave. But once I connected it as a slave, I am NOT able to MSTSC/RDP into the machine. I can still access the machine via ssh/cygwin.
( I repeated the process several times and ended up losing rdp connectivity everytime )
This is what is actually happening now :
The EventLogs on machine are saying that logoff instructions are being initiated by the RDP client.
RDP client is saying "The disconnection was initiated by the user logging off their session on the server"
Visually, if seems like the remote connection was setup for a split second. Then it vanishes.
So, I believe that somehow my Administrator account is not able to maintain the session. It's getting disconnected as soon as it connects.
Can you suggest me which settings should I debug into ? I am able to extract a few details from my machine using ssh, but I can't explore all the settings.
If you are familiar with this behaviour please suggest me what settings might be reponsible for this.
Addition info:
If I restart my ec2 , it will never come back because a status check starts failing
I am able to telnet to 3389 port. So I guess, firewall rules are not an issue.
I have tried various RDP clients, on MAC as well as on Windows.
I found this in event log (ProviderName: Microsoft-Windows-RemoteDesktopServices-RdpCoreTS) on my remote windows machine:
5/10/2019 3:13:44 PM 103 Information The disconnect reason is 12
.
.
.
5/10/2019 3:13:43 PM 228 Warning Disconnect trace:CUMRDPConnection Disconnect trace:'calling spGfxPlugin->PreDisconnect()' in CUMRDPConnection::PreDisconnect at 4477 err=[0xc], Error code:0xC
It turns out the my problem was occuring due to some cleanup utility deleting up the system files required for mstsc.
Everything started working fine after I switched off the cleanup utility.
Thanks for the help though.
After rebooting my Windows Server 2016 Standard (SQL Server 2016) my SSIS process that runs this query:
select * from openquery(HRMPROD, 'SELECT QUERY HERE' )
started failing with this error:
I get the same error if I try to run the query in SSMS. I have the same linked server set up on my test instance and the query is successful when I run it there. I have compared the linked server create script on both instances and it is the same.
Any idea where I should look for what is causing the connection issue on the one server but not the other?
Thank you.
Saying the answer is on the Oracle side is just like pointing fingers across the way. Let's just fix the issue here.
There is a connection string that is used from SSIS, (which you also used in SSMS) The connection string contains three main components to connect and would result in the 12154 error if any of them were incorrect:
Host
Instance name (different than Instance on Sql Server, think database name)
port
The port most likely hasn't change, neither has the database name, but the host...No, hasn't changed, but the DNS server used to connect most likely has! I would ping the host and see what returns from the SSIS and your SSMS host that you're using. I would expect it to fail. Find out what IP address the host is using and ping that - see if it returns. I'm guessing that's the change that needs to be updated or your Network folks need to fix a DNS configuration/server issue.
Hope this helps!
Kellyn
Since you are getting a response from the TNS Listener, the problem lies on the Oracle side. See Architecture of Oracle Network Services for an overview of how the Oracle networking handles things. Keep in mind that based on the error message you've reached the TNS Listener, so you only need to check things between TNS and the Oracle database... In other words, your networking and SQL Server settings are fine or you wouldn't be able to get this error message.
I would agree with above that the issue might have to do with the network. I have come across that a few times, where we can set everything up, but a firewall is blocking communication between the two servers.
Open up powershell on the new server and run a tracert to the target to see the hops and identify if is connecting across the network.
If it is, then run a test-netconnect on the specific port, to see if the port is open from the firewalls.
Cheers!
We have an Oracle server set up and are using TCP with SSL as connection. This setup was made with the assistant wizard and we used the default settings pretty much everywhere (which also means that no tnsnames.ora or listener.ora exist). lsnrctl status shows that the correct ports are listening.
We are trying to connect to this database via DBeaver and SQuirrel SQL but cannot get it to work. We have set the vmargs for the programs to contain the certificate of the server (e.g. dbeaver.exe -vmargs -Djavax.net.ssl.trustStore=C:/...keystore.jks -Djavax.net.ssl.trustStorePassword=password -Djavax.net.ssl.trustStoreType=JKS), which works fine.
Connecting to the database with a concrete JDBC URL string (jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=IP)(PORT=5500))(CONNECT_DATA=(SERVICE_NAME=testdb)))) does not work and times out after 60 seconds without a proper error (IO Error: Got minus one from a read call). We have tried pretty much everything and cannot get it to work.
The ports are correctly assigned, the database can successfully get accessed with the normal TCP protocol and port 1521.jdbc:oracle:thin:#(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=IP)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=testdb)))
Are we missing steps? There don't seem to be any firewall issues. The certificates seem to be working fine as well, but we cannot connect with any of the programs (or sqlplus via command line).
Anyone know what could be the problem? Thanks!
Can you check out the SSL blog or our OTN page for step-by-step instructions? If you are using TLSv1.2 then the JDK version and JDBC driver versions are very important.
In the end I got it to work. There are various sites online that show you how it's done. I used this one:
https://database.edorex.ch/blog/database-connection-with-a-certificate/
Getting the wallets set up, certificates set up and the user set up in the database were the most important steps. Additionally, I had to separate the server and client machines. The server is now on a VM and it works that way, I couldn't get it to work having both on the same machine.
Some context: I'm setting up an environment to run some Ruby code our Lead wrote to connect to some remote Databases. I'm using Win10 and have WSL installed. I have installed SQL*Plus, docker, and Ruby, and am sure I have installed all the dependent gems (actually at this point I know for a fact its not a ruby problem). I'm using Docker to use a pre-built image of an Oracle Database, and I have populated it with data.
Obfuscated company DB information:
'Broken' DB (TNS no listener)
Username: W-WORK-DEV
Password: password
Host: host1
Port: 999
SID: W-WORK-DB.tech.company
'Working' DB (can connect just fine)
Username: C-OLD-DEV
Password: password
Host: host2
Port: 999
SID: C-OLD-DB.tech.company
Please note the names I have provided here are purely for obfuscation, they do not represent anything about age or even config. They are essentially the same, just different databases on different hosts. Also note this is a corporate company and would have a lot of base infrastructure for their internal network.
The issue I am having is that with the specific database I am working on, I cannot connect to it. I connect to the company intranet via a VPN (I work offsite) and have issues connecting to WORK-DB.tech.company, though I can connect to C-OLD-DB.tech.company. Methods I have tried to connect with:
Oracle SQL Developer
I have inputted all the correct jdbc strings and username / password. Have even asked other people to attempt to connect (at least 3 others). They can all access C-OLD-DB as well as W-WORK-DB. When using this method, I get The network adapter could not establish the connection.
Side note: I'm fairly sure I have connected to the DB just fine in the past, though I can't be certain because I'm fairly new to this team and have only accessed it once, if that.
SQL*Plus via WSL
I installed SQL*Plus because I think Ruby was accessing it in some capacity when running the script. I got to the point where the script was able to connect to my local docker Database, but when it tried to connect to the remote database, it would return TNS: no listener. I attempted this using sqlplus as well and got the same error.
Example:
sqlplus C-OLD-DEV/password#host2:999/C-OLD-DB.tech.company
This command works and connected to the DB jsut fine.
sqlplus W-WORK-DEV/password#host1:999/W-WORK-DB.tech.company
This command gave me TNS: no listener.
During my research I had found mentions about tnsnames.ora, sqlnet.ora, and listener.ora. I have found relevant files around the company intranet and attempted to use them in my own personal environment to no avail (one of the sqlnet.ora files actually stopped me from being able to connect to any) I found mention about a config/database.yml file related to ruby, but our code already has the database information set up and I seem to be getting to the same solution as the script when trying to manually connect via sqlplus.
Here are some relevant environment variables I have set up when doing these installs. I'm thinking that at some point when trying to set up my environment, I messed up some config that changed the way sqldeveloper or sql plus would connect to that database.
$ echo $ORACLE_HOME: /usr/lib/oracle/12.2/client64/
$ echo $TNS_ADMIN: /usr/lib/oracle/12.2/client64/network/admin
$ echo $LD_LIBRARY_PATH: /usr/lib/oracle/12.2/client64/lib
I hope I have provided all the information I have come across and have explained clearly what my issue is, if you have any questions feel free to comment about it so I can clear it up. Thank you for any and all your help.
So my problem ended up being a 'firewall/port' issue. In the end i found out that specific port I was connecting to was blocked, but I thought it was only on my system. Turns out the VPN I'm using was the issue blocking that port. Company has a Primary Data Center and a Secondary one, and apparently the SDC VPN was blocking that port from me. I switched to using the PDC VPN and it worked.
Are you using the 64 bit jdbc drivers?
I am installing Firebird (v1.5.5 - I know it's old but it works) on a new computer which is running Windows 7. I have installed the classic server version as a service. According to documentation at the Firebird site, I modified the firebird.conf file so that IPCName would be global\FirebirdIPI; I did this while the service was not running.
Despite all my efforts, I have been unable to access any of the databases which I copied to this new computer via ISQL. FWIW, the EMS SQL 2005 manager program is successful in accessing the databases, but this program apparently has a direct method which does not require fbclient.dll.
What else should I be checking?
Update from a few days later. After wasting a great deal of time with Windows 7, we decided to downgrade the computer and run XP. After installing the superserver version of FB 1.5.5, I can run my programs and access the databases which are stored on this computer. Attempts to access the databases from other computers connected on the network failed with a variety of error messages, but normally something like 'i/o error for file !firebird!\db\q400.fdb'.
In order to allow people on the network to continue to access the databases, I revived the NT server and started the Firebird service - and all the programs can access these databases successfully from remote computers!
To simplify matters, there are three computers on the network:
the NT server ('zorcomp'), which is running the Firebird service; the fdb files reside on this computer in a directory called 'db' which sits under a shared directory called 'firebird'
a computer running XP, called 'kivserver', which also has a shared directory called 'firebird' and underneath that a directory called 'programs'. Copies of all the fdb files reside in a directory called 'db'.
a computer running XP, which maps \zorcomp\firebird to disk L: and \kivserver\firebird to disk T. From this computer, I can run a program sitting in T:\programs and get it to access successfully a file sitting in L:\db. If I stop the FB service on zorcomp and start the same service on kivserver, the same program cannot access files sitting in T:\db.
I hope this is clear enough. For the life of me, I can't see any difference between all the files which are residing in \kivserver\firebird to those which are sitting in \zorcomp\firebird - but somehow there is a difference!
Obviously, I don't want this arrangement to continue - the NT server has to be retired honourably.
Further edit. I now have the firebird server running on 'kivserver' (NT). I can access the database files locally.
Computers running Win7 can now access these database files using a connection string \\kivserver\firebird\db\database.fdb.
Computers running XP cannot access these database files, although IIRC wisql did succeed with \\kivserver\firebird\db\database.db.
The NT server has been disconnected from the network.
TIA,
No'am
AFAIK EMS SQL uses fbclient.dll (or a wraper around it).
If the only thing you want is to access the databases, I suggest you to do so using TCP protocol instead of the local protocol. To do it connect like this:
c:\>isql localhost:c:\path\to\db.fdb -u sysdba -p masterkey
Unless you're avoiding TCP or the machine have no local interface enabled, it will do the work for you.
Try using this to connect to your database:
hostname:drive:\complete path\filename.fdb
or
\hostname\drive\complete path\filename.fdb
May I know the component you're using?
If your clients are Windows 7 then you might try to use \\hostname\sharename\filename.fdb instead of drive:\filename.fdb connection string.
Several months later, the NT server was somewhat abruptly retired when it displayed 'MBR error' on rebooting after someone unlugged it by accident. Thus I was left with no option but to start running the Firebird server program on 'kivserver'. The connection problems returned.
Eventually I was able to solve the problem with the following connection string
10.0.0.202:e:\firebird\db\manager.fdb
where 10.0.0.202 is the ip address of the server, and e:\firebird\db the directory in which the database sits, relative to the server itself.
I hope that someone else, some time, will find this information useful.