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
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.
We have sql 2000 databases on our internal network secured behind ISA Firewall. Up till now we have not opened tcp port 1433 to allow external sql traffic in or out. We also have a remote external website with a later version of sql on.
Is there any way to update the external database from our internal network without increasing the chance of anyone hacking into our internal network?
The Sync Framework does this for most cases. I'd recommend against opening up your firewall to allow anyone to connect to your database server - that's pretty much inviting hackers to own your data.
The Sync framework works natively with SQL Server 2000 SP4 and later - though you can probably find a provider for older versions if you try. By using a provider framework, Sync can in principle connect to any data source.
I made a GUI software in Matlab that will access my SQL server database. So far, I have been able to access the database from all of the computers in my lab. However, these computers are all on the same network, and the database will need to be accessed through networks outside of the lab. I can already access my database using another instance of SQL Server from my home. My question is, is it possible to access my database from an outside network using Matlab and the JDBC driver?
Here is the TechNet article: http://technet.microsoft.com/en-us/library/ms175483%28v=sql.105%29.aspx
Main things are: TCP/IP libraries enabled on SQL Server(that better be on anyway). Incoming ports enabled. Defaults are TCP 1433 and UDP 1434, but you may have changed those during installation if you used named instances of SQL SErver.
A client of mine gave me a server name which is fully qualified [servername].somedomain.net
to try to connect to their SQL Server instance over VPN.
So I tried, using the username and password they gave me. No luck. I can ping it but cannot connect, I get the error that the username and password is incorrect.
So I log onto the actual server, verify that my login is in security and has rights and it appears there. Workgroup\mylogin and it appears that workgroup\ actually is the same as somedomain.net\mylogin. Because when I try to add somedomain.net\mylogin, it resorts to saying that it's already added which is workgroup\mylogin.
Not sure what else to check here. I gave myself sysadmin role in SQL Server. I can ping the server's IP.
I looked at how they are authenticating me and they have my user in SQL Server set up to use Windows Auth. Well, the error I get is that it cannot trust cross domain when trying to use windows auth when I try to connect locally here in my management studio. I'm connected tot their VPN so what could be the problem?
They're not available right now to try to troubleshoot it and I'm just curious what else I might try to try and resolve this on my own if I can.
Basically, when you failed to connect to your SQL Server, the issue could be:
Network issue,
SQL Server configuration issue.
Firewall issue
Client driver issue
Application configuration issue.
Authentication and logon issue.
Step 1: Network issue
You might be able to make local connection without a working network, but that's a special case. For remote connection, a stable network is required. The first thing to trouble shoot SQL connectivity issues is to make sure the network we rely on is workable and stable. Please run the following commands:
ping -a (use -4 and -6 for IPv4 and IPv6 specifically)
ping -a
nslookup (type your local and remote machine name and IP address multiple times)
Be careful to see any mismatch on the returned results. If you are not able to ping your target machine, it has high chance that either the network is broken or the target machine is not running. It's possible the target machine is behind a firewall and the firewall blocks the packets sent by ping, though. Windows firewall does not block ping (ECHO) packet by default. The correctness of DNS configuration on the network is vital to SQL connection. Wrong DNS entry could cause of all sorts of connectivity issue later. See this link for example, "Cannot Generate SSPI Context" error message, Poisoned DNS.
Step 2: SQL Server configuration issue
You need to make sure the target SQL Server is running and is listening on appropriate protocols. You can use SQL Server Configuration Manager (SCM) to enable protocols on the server machine. SQL Server supports Shared Memory, Named Pipes, and TCP protocols (and VIA which needs special hardware and is rarely used). For remote connection, NP and/or TCP protocols must be enabled. Once you enabled protocols in SCM, please make sure restart the SQL Server.
You can open errorlog file to see if the server is successfully listening on any of the protocol. The location of errorlog file is usually under:
%ProgramFile%Microsoft SQL Server/MSSQLxx.xxx/MSSQL/Log
If the target SQL instance is a named instance, you also need to make sure SQL Browser is running on the target machine. If you are not able to access the remote SQL Server, please ask your admin to make sure all these happen.
Step 3: Firewall issue
A firewall on the SQL Server machine (or anywhere between client and server) could block SQL connection request. An easy way to isolate if this is a firewall issue is to turn off firewall for a short time if you can. Long term solution is to put exception for SQL Server and SQL Browser.
For NP protocol, please make sure file sharing is in firewall exception list. Both file sharing and NP use SMB protocol underneath.
For TCP protocol, you need put the TCP port on which the SQL Server listens on into exception.
For SQL Browser, please put UDP port 1434 into exception.
Meanwhile, you can put sqlservr.exe and sqlbrowser.exe into exception as well, but this is not recommended. IPSec between machines that we are not trusted could also block some packets. Note that firewall should never be an issue for local connections.
Step 4: Client driver issue
At this stage, you can test your connection using some tools. The tests need to be done on client machine for sure.
First try:
telnet
You should be able to telnet to the SQL server TCP port if TCP is enabled. Otherwise, go back to check steps 1-3. Then, use OSQL, SQLCMD, and SQL Management Studio to test sql connections. If you don't have those tools, please download SQL Express from Microsoft and you can get those tools for free.
OSQL (the one shipped with SQL Server 2000) uses MDAC.
OSQL (the one shipped with SQL Server 2005 & 2008) uses SNAC ODBC.
SQLCMD (shipped with SQL Server 2005 & 2008) uses SNAC OLEDB.
SQL Management Studio (shipped with SQL Server 2005 & 2008) uses SQLClient.
Possilbe command use be:
osql -E -SYour_target_machine\Your_instance for Windows Auth
osql -Uyour_user -SYour_target_machine\Your_instance for SQL Auth
SQLCMD also applies here. In addition, you can use “-Stcp:Your_target_machine, Tcp_port” for TCP, “-Snp:Your_target_machine\Your_instance” for NP, and “-Slpc:Your_target_machine\Your_instance” for Shared Memory. You would know if it fails for all protocols or just some specific procotols.
At this stage, you should not see general error message such as error 26 and error 40 anymore. If you are using NP and you still see error 40 (Named Pipes Provider: Could not open a connection to SQL Server), please try the following steps:
a) Open a file share on your server machine.
b) Run “net view \your_target_machine” and “net use \your_target_machine\your_share” (You can try Map Network Drive from Windows Explorer as well)
If you get failure in b), it's very likely you have OS/Network configuration issue, which is not SQL Server specific. Please search on internet to resolve this issue first.
You can try connection using both Windows Authentication and SQL Authentication. If the tests with all tools failed, there is a good chance that steps 1-3 were not set correctly, unless the failure is logon-related then you can look at step 6.
If you succeeds with some of the tools, but fails with other tools, it's probably a driver issue. You can post a question on our forum and give us the details.
You can also use “\windows\system32\odbcad32.exe” (which ships with Windows) to test connection by adding new DSN for various drivers, but that's for ODBC only.
Step 5: Application issue
If you succeed with steps 1-4 but still see failure in your application, it's likely a configuration issue in your application. Think about couple of possible issues here.
a) Is your application running under the same account with the account you did tests in step 4? If not, you might want to try testing in step 4 under that account or change to a workable service account for your application if possible.
b) Which SQL driver does your app use?
c) What's your connection string? Is the connection string compatible to your driver? Please check http://www.connectionstrings.com/ for reference.
Step 6: Authentication and logon issue
This is probably the most difficult part for sql connectivity issues. It's often related to the configuration on your network, your OS and your SQL Server database. There is no simple solution for this, and we have to solve it case by case. There are already several blogs in sql_protocols talking about some special cases and you can check them see if any of them applies to your case. Apart from that, things to keep in mind:
a) If you use SQL auth, mixed authentication must be enabled. Check this page for reference http://msdn.microsoft.com/en-us/library/ms188670.aspx
b) Make sure your login account has access permission on the database you used during login ("Initial Catalog" in OLEDB).
c) Check the eventlog on your system see if there is more information
Reference: http://blogs.msdn.com/b/sql_protocols/archive/2008/04/30/steps-to-troubleshoot-connectivity-issues.aspx
Sorry for this wall of text, i hope that something from here can help you solve your issue!
Regards.
If you want to access that server you are going to need a domain account from that domain or use SQL authentication. I would recommend just using SQL authentication - it's a lot more straight forward - if they allow it.
I had the same problem, other machines could connect to sql server but one computer was not connecting and displaying the error "a network related or instance specific error...", the problem was solved when I changed the network protocol in the login window of SSMS, in advanced options from TCP/IP to Named Pipes. Please see the below screenshots.
Please note that you should be on the same domain, and your credentials should be valid on the server.
I have a Delphi application running on SQL Server 2000, but it's taking awfully long to connect to the database!
But when I run this application on my development server it connects pretty fast!
I am running on Windows 2003 server, SQL Server 2k personal edition, when I look on my MDAC version in the registry, I see version 2.8 already installed!
Any ideas why this happens on the production machine but not on the development machine?
There's a reasonable chance that this is down to a network level issue connecting to the database. Depending on whether you're running the application and database on the same box of course.
Try connecting to the database from the same machine using a different tool. You could set up a data source and test it from the control panel as an alternative. If the connection is slow from another tool test the connectivity between the servers for other types of connection (e.g. run a ping). It may be that it's resolving the server via broadcast rather than the domain, for instance. Or any number of other issues - firewall, switch, wins etc.
If you are connecting using integrated authentication also ensure that the database can resolve the application server as well as vice versa. This is part of the authentication process and I've seen it cause slow downs in creating database connections before.
In short, I'd be confident that this isn't a problem specific to delphi / sql, but something in the communications between your production servers.
Good luck!
Keep your connection open once you have established it. This is called connection pooling and will improve performance. I have no clue how to do it with a delphi application.
Your problem most likely is network or transport layer related
Are you connecting through TCP, Named Pipes or another mechanism?
Have you tried tracing opening a connection with Microsoft SQL Profiler?
regards,
Lieven
I had a problem a long time ago like this, and it came down to the workstation section of the connection string. its possible if you've copied the connection string from your dev machine that the workstation parameter is still in the connection string and pointing to your dev machine which probably does not exist on your deployment network.
In this case your connection to the database has to wait until the network tries to connect ot a non-existant machine (which obviously takes time). Remove the workstation cluse and it will speed up no end.