Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to connect one of our clients "as is" programs to a remote database instead of a local one, they think that they have coded it to work that way, but for some reason the program crashes when trying to connect to a remote database. I don't have the source code so I can't really dig much deeper than that and the company does not provide any upgrades or custom modifications. I can succesfully connect to the database through SqlDbx and HeidiSQL so I know that the server is set up correctly.

This is why I need to find a way to spoof a remote connection on port 1433 to appear like a local database connection to the program. I thought about editing the hosts file, but it will most likely crash other programs if I bind localhost to another IP than

Any ideas?


I've tried solving it other ways like suggested, but I've tried everything I can think of.

  • It's the same versions of all the programs
  • TCP/IP works instead of Named pipes on localhost and with works with sqlviewers like sqldbx and heidisql
  • Authentication works with sqlviewers
  • The configruation is only the fields needed for the database connection string

The only thing that I can see is left is that there is something restricting it from inside the code which I have no control over.

share|improve this question
If the program is capable of connecting to a remote database but crashes when trying to connect why don't you work on resolving that problem instead of trying to "hack" a solution? If you're having trouble finding the cause of the problem then go to the vendor and get their assistance. This seems like a misguided method for fixing the problem. – joeqwerty Nov 11 '13 at 4:53
@joeqwerty: I don't have access to the source code and the company developing it does not provide any custom modifications. I don't see any other solution to this than doing a hack. – spydon Nov 11 '13 at 4:56
I don't understand. You stated that the program has been coded to be able to connect to remote databases, so why would you need access to the source code? Why would the vendor need to provide a "custom" modification? The program is capable of connecting to a remote database, according to you, so why not work with the vendor to troubleshoot it? – joeqwerty Nov 11 '13 at 16:43
I wouldn't call the people who wrote the program professionals, they barely know how to code but somehow they manage to sell this program. When they say that they have coded it to be able to do something it's more of a guess from their side and we have to find out if it's true or not. – spydon Nov 11 '13 at 22:23
up vote 3 down vote accepted

Essentially, you're trying to work around what appears to be somebody else's bad implementation. That seems reasonable to me, and sometimes, that's a necessity. If this program is indeed "crashing" when trying to connect to one database but not another, as opposed to, oh, you know, displaying an error message, that's pretty weak.

I have a standby solution for this in Linux ("redir") ... but not Windows; however, I found this in the Google machine:

I tested it just now with the "Cygwin" version -- no install required, it has an exe and a DLL and it "just worked" on my Windows 7 laptop. Neat little bonus, it has a --log-to-stdout option which, combined with > into a file, logs the bytes sniffed from the stream (might be interesting reading). I didn't have a SQL Server handy, but I tested it with some other TCP services and it seems to work as intended -- it listens on a local socket, and when connections come in, it makes a connection to a designated socket on a remote machine, and ties the ends of the pipes together. Listening on 1433, it "should" do the trick.

It's going in my toolkit, anyway.

share|improve this answer
That is exactly what I need, thank you! – spydon Nov 12 '13 at 2:53

While you certainly could use techniques like SSH port forwarding to make a remote listening TCP socket appear like a local one, it probably would not be of any help.

If your client is "crashing" upon connection, it most likely would not stop doing so just because you are using a different destination IP address.

There might be a myriad of reasons why the software is running fine when connecting to a local database but becomes troublesome with a remote database, including but not limited to

  • version issues
  • use of different protocols (Named pipes vs. TCP/IP)
  • authentication issues (integrated authentication might work locally but break for remote systems)
  • configuration issues

You should direct your efforts towards the problem's diagnosis instead of doubtful workaround attempts.

share|improve this answer
I agree that this should be solved another way, but I've tried everything I can think of. It's the same versions of all the programs, TCP/IP works instead of Named pipes on localhost and with works with sqlviewers like sqldbx and heidisql, authentication works with sqlviewers, the configruation is only the fields needed for the database connection string. – spydon Nov 12 '13 at 1:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.