I have a web server (Coldfusion) and 2 remote networks that have SQL servers. For both remote offices/networks I query for data every 10 minutes. It has been working for some time now. In one of the offices/networks, AT&T dumped our public static IP address. They assigned a new one and I have made the appropriate changes to the firewall. Now I can use the Windows ODBC manager and test the connection from the web server and it passes just fine. But, when I try to verify the Coldfusion data source, it fails, "timed out trying to establish connection".
ColdFusion 9 doesn't use the Windows ODBC drivers; it uses JDBC drivers. Changing the Windows ODBC drivers and testing them will have no affect on your CF sites.
Update your DSNs in ColdFusion Administrator. Remember, you access your CFAdmin via:
http://localhost/CFIDE/Administrator
unless you've specifically changed it during install. Obviously, replace "localhost" with the server's IP or hostname if it is externally hosted.
ADDENDUM
The exception to the above rule is when you are using the ODBC-JDBC Bridge (CF DSN type = "ODBC Socket"), in which case, you need to verify that:
a) The Windows ODBC Driver (System) is set up, tested, and working, and
b) The CF DSN is pointing to the correct Windows ODBC Driver.
If you are using Windows Server 2008 64-bit, then you may be having trouble with your ODBC because you could be looking at the 64-bit connection list, rather than the 32-bit. In this case, you will have to open up c:\windows\syswow64\odbcinst.exe to access the 32-bit ODBC manager (yes, you read that right; the 32-bit version is under a folder named syswow64).
It sounds to me like there is a good chance that the driver settings you need to update are there, instead of those found registered under the 64-bit ODBC manager (which is the default ODBC manager under control panel). You may have actually had duplicate ODBC entries, one under the 64-bit list and one under the 32-bit list, and this could be the source of the confusion - CF could be using the 32-bit version. In any case - this would be a good thing to check.
Related
I use an online database which I am able to connect through altium or dbVisulizer. I want to add an instance to that database using ODBC Data source in windows, but it fails. The steps I followed are pictured below:
Any idea why is this happening?
Additional information:
Altium use the following information: ConnectionString = Provider=SQLNCLI11.1; User ID=alib_WFC5AKIMTQCL; Password="*********"; Initial Catalog=altium_library; Data Source=db.altiumlibrary.com,1433; Initial File Name=""; Server SPN=""
After connecting through dbVisulizer I have the following information: The server version is: Microsoft SQL Server 14.00.2027 Microsoft JDBC Driver 9.2 for SQL Server 9.2.1.0
I don't believe this is possible. However, in most cases, if you can connect to sql server via jdbc drivers, then you can connect to the same sql server with odbc.
Access does not support jdbc, and in most cases that driver is Java, and thus you would be talking about a java enabled client side software.
For example, I have a instance of SQL server. I direct connect from Access over the network to SQL server - using ODBC drivers.
However, my android phone? Well, I use jdbc type 4 drivers, and thus my android phone can also direct connect to that same instance of sql server on the network.
However, there is no support for Access to connect to SQL server using jdbc drivers, but then again, if that is SQL server in question, then both jdbc, and odbc should be able to connect to that running instance of SQL server.
Now, you might be able to setup and run what is called a jdbc "bridge" connection. This would require that you install + setup a bridge on your computer. (and that bridge runs like a mini web server - it is NOT just a driver, but a web like "service"/"server" that you have to have running. In fact, it quite much the reverse that such a bridge is for. So, for example, if you running that bridge, then it would be possible for jdbc drivers to in fact connect to the access database (this would be a type 2 (or 3???) jdbc driver/connection.
So, to be clear, a jdbc type 4 connection is NOT possible to Access, since they require a so called "socket" (tc/ip) connection. Access is file based, so you don't ever connect to a access database, but you OPEN IT as a file. However, as noted, you are talking about Access connecting to the server anyway.
However, Access does not support, nor use nor have any means to use and consume a jdbc driver. But then again, it stands to reason that any database from MySQL, Oracle, PostgrSQL, SQL server, and more ALL HAVE ODBC drivers.
So it begs the question, why a ODBC driver would not be used here?
But, as noted, since Access supports ODBC drivers, and not jdbc drivers, then the answer is no - Access cannot use such drivers.
Trying to setup an ODBC connection for UPS to access our SQL server, from our shipping client computer.
I have scoured as much as I can an ran across:
runas /netonly /user:domain\account "c:\windows\system32\odbcad32.exe"
Now, using this method, on my current client computer, I was able to setup an odbc connection successfully using SQL Native Client 11 (5058). I am using Win 10. Our shipping computer, with multiple manifest systems on it, is still using Win 7, but otherwise is setup the same on the domain.
Using the same process as above, the connection ultimately times out, and states that the server is not online/not available/not allowing remote connections.
Is there a step I'm missing? Both clients have same rules for firewall, both are using the same user/password in the runas cmd. The only difference between the two clients is Win 10 vs. Win 7, and the current logged in user is different (but that shouldn't matter with the runas cmd?)
Thanks!
So after several days/hours of trying various solutions and suggestions from all over the interwebs, I came across this solution/tips.
In SQL Server Configuration, checking the network configuration protocols/clients/aliases. In my case, there was an aliases established for 32-bit, and not 64-bit. I disabled the 32-bit one.
I then found suggestions to us the ip (which I had tried in the past, with no success), but this time, after ensuring all the tcp/ip protocols were enabled and the 32-bit aliases was disabled, I was able to connect the 32-bit to the 64-bit SQL server, using the xxx.xxx.xxx.xxx address of the server.
Test came back successful!
My Problem is that I cannot connect to an SQL Server Express 2008 64bit Database via an Access Runtime 32bit, neither by Windows authentification nor by SQL auth.
On the Windows 2011 Small Business Server runs a Virtual machine with Windows 7 Prof. 32 bit. From this Windows I tested my Access App. using a (32bit) SQL Driver 11, which works fine.
The same Access App used from a 64 bit Windows 7 Prof. Client using a 64bit SQL Driver 11 fails with SQLState 08001 error.
The Thing which I do not understand is, that ODBC Connection test is successful, a data link (UDL) is successful, but not my Access App.
When starting the app, the first Thing is to run a stored procedure through a passthrougquery and grab data from a certain tbl in the SQL-Database. This SP brings the Connection error, but not an runtime error from Access (I removed even an error handler!).
So, how can I find the reason or any error in the Access app (if there is one)?
I am helpless as anything I know to test or to do I already tried out to make the app run. As I cannot even install the SQL Driver 11 in 32bit, it should not be a Driver related error.
Does anyone know a test-app, where I cannot only connect but retrieve data from an SQL-Database or any other tricks to check the Access to the database?
Thanks your help!
Access usually is installed as a 32bit Application. So on 64bit computers it will use the 32bit subsystem. On Windows 7 all the default shortcuts to the ODBC Data Source Administrator utility will lead to the 64bit version of it. Whatever you see or configure there is completely irrelevant, as your 32bit Access is not going to see it.
Solution:
You need to explicitely open the 32bit version of the ODBC Admin utility and configure the data source there.
To make sure you get the right version, use Windows Explorer and open this file: C:\WINDOWS\syswow64\odbcad32.exe
Well, what I found out meanwhile is, that the Connection Fails when trying to use a Connection like this "ODBC; DSN=MyDSN;....." but it works, when I make a Connection DNS-less, by connecting with "ODBC;DRIVER=SQL Server Native Client 11; SErver=myServer;....".
Maybe this is exactly that what you are talking aout. When I just use a DSN it takes the wrong bit Version.
So I will try this: delete the DSN I have, open odbcad32.exe and create the same DSN again.
If I understand you correct, then Win 7 provides the correct Driver and stores it in the DSN. Calling this DSN by Access would lead to the correct Settings.
Further Problem is, that my SSQL-Server instance is not at port 1434, and the SQL Server Native Client 11 Driver has no more Clientconfiguartion to set the static port. So I found a string solution for that "MyServer\Myinstance, 15999".
I hope that this port Setting will be accepted in the DSN, otherwise I really have to Change to DSN-less which is more complicated due to different Servers for the development and the production.
Thanks yr. reply.
I have a problem connection to a SQL Server 2012 instance running on Windows Server 2012. I have a .NET 4.5 windows forms application installed on a client machine running Windows 7. The error I get is this:
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: SSL Provider, error: 0 -
The wait operation timed out.)
My connection string looks like this:
server=SERVERNAME;database=DATABASENAME;User Id=someuser;password=somepassword;Timeout=60;app=LabelMaker
I tried connecting to the SQL Server from the client machine using QueryExpress
and that worked! My app is 64-bit if that is of any help. I've checked every setting I can think of in SQL Server. No force encryptions are enabled on the protocols (shared memory and tcp/ip), the domain firewall is open on the server. I've tried various connection strings with all kinds of unheard off parameters, always the same result, failure.
I'm really confused about why it works with QueryExpress? My app works when connected to a remote instance of SQL SERVER Express on another machine, it also works if I run it on the SQL Server 2012 machine.
I've also tried connecting to the server from the client machine with LinqPad and this is also really weird, with the new version based on net4/4.5 (Version: 4.43.06) it fails but when I use the old version of Linqpad (2.x) based on net3.5 it works!
It seems like Panda Security is causing the problem, I ran
netsh winsock show catalog
and found a few panda entries, I then did a reset
netsh winsock reset
now my application works fine, I then rebooted the machine, ran the catalog command again,
the panda entries were back and my app is having the same problem as before.
Here are the Panda entries in the winsock catalogue: https://gist.github.com/pellehenriksson/5159883
All ideas and suggestions are appreciated.
UPDATE
Panda Security v5 is the cause of this problem, this has been confirmed by Panda support.
The root cause of the problem is explained by Alex below. The customer will do an upgrade to v6 of Panda Security, I will test again after the upgrade.
CONCLUSION
Moving to Panda Security v6.0 fixed this issue.
This seems to be a non-Microsoft related issue: Visual Studio 11 beta installation disabled my abillity to connect remote MS SQL Server but not local databases.
The ticket has been closed as external.
The only workaround available at this time on Microsoft Connect is:
Posted by Lars Joakim Nilsson on 5/4/2012 at 5:03 AM
My machine had this problem. The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider. Se
http://support.microsoft.com/kb/2568167
/Lars Nilsson
The SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed link gives the resolution:
Not specifying the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag or
removing any non-IFS Winsock LSPs installed. Also moving from a
non-IFS LSP to Windows Filter Platform (WFP) can resolve this issue.
So, you should remove Panda Security or, as an alternative, you may try to execute netsh winsock reset as a pre-build command (although I'm not sure if this is effective without a reboot), which would let you develop/debug your application.
[UPDATE]
More information about application compatibility is given here: Application Compatibility in the .NET Framework 4.5:
Data
SQLClient
Feature
Ability to connect to a SQL Server database from managed code that
runs under the .NET Framework 4.5.
Change
The existing synchronous API code path was modified to add
asynchronous support.
Impact
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to
connect to SQL Server. For more information, see
SetFileCompletionNotificationModes API causes an IO completion port
not work correctly with a non-IFS LSP installed on the Microsoft
Support website.
I hate to say it, but restarting Visual Studio and my Microsoft SQL Server Management Studio solved this problem.
At work we have a SqlServer database that cannot be connected to from outside our internal network. If we want to work remotely we can ssh into several other servers on our network and then work via X Forwarding so the development applications have access to the database.
This is annoying for a bunch of obvious reasons such as latency in the IDE and I'm wondering how I could tunnel the database connnections back to my machine. It seems like this should be possible but I'm not sure how to do it since there's has to be an intermediate step in between. This question is similar to what I want to do but only works for going directly to the db server if I understand it correctly.
I'm asking specifically about ODBC because that's the driver the application already uses. If there is a more general solution I would of course be open to that.
What I want to do is
Local machine (Linux) -> Server (Linux) -> Database connection to DB (Sql Server)
Well, as you say, if you wanted to directly use a encrypted connection to SQL Server you could just use Linux driver that give you that, and most I think do. You could use a bridge as already suggested. But It might be possible using socat. What driver are you using on the local machine? I will have a quick play and see how it works.
The OpenLink Software - Multi-tier ODBC Driver for SQL Server might help you out here...
It has a client server architecture as which can easily be configured in a three-tier (client/proxy/server) architecture as follows --
Linux Client -
ODBC Application
OpenLink Generic ODBC Driver (Multi-tier client component)
Linux Proxy -
OpenLink Request Broker (Multi-tier server component)
OpenLink Database Agent for SQL Server (Multi-tier server component)
Windows Server -
SQL Server DBMS