Disclaimer: I'm a web developer, not a DBA or network admin, so if the following is a totally stupid question, please be gentle---
I am trying to come up with a somewhat decent testing environment (they have no staging area) for a client for whom I'm converting a static HTML site to ASP pulling content from SQL Server.
I'm running Windows 2000 Professional at home and its slightly-watered-down version of IIS webserver, which is fine for testing ASP that doesn't talk to a database. My question is, is there any way that my home webserver can talk to their production SQL Server installation?
My working setup is this---I can connect via Remote Desktop to their webserver machine, which has a copy of Enterprise Manager installed, which has a database registration for a SQL Server installation on a physically separate machine. Given those couple of degrees of separation, I have no idea how locked-down the actual SQL Server box might or might not be as far as the outside world goes.
So, several questions:
Is there a way, without access to the machine console, to figure out if the SQL Server box has an Internet IP address I can try to set up as an ODBC DSN?
Given access to Enterprise Manager for that SQL Server install, are there settings I can check and/or configure to make this happen?
And if this is the sort of thing I wouldn't be able to resolve myself, is there anything specific I can ask the client's tech staff to see if I can get what I need?
I hope this is coherent. If the answer is "dude, you need to talk to the network admin" I'll do that... it's just I'd always rather learn how to do something myself when it's possible :)
Since you can get a terminal session going between yourself and them, it sounds like you can get onto their network. If you are using the webserver's name to connect to the webserver, then you are using their DNS, and you are practically all set.
As a rule, no IP addresses should be used in code, except for raw
testing. Any server should be addressed by it's DNS or other network
name. This way, if an IP address changes, or a machine is replaced,
the application is not affected.
If you can not use a DNS name (I have seen some VPN connections forbid using others' DNS Servers) for the SQL server on your local machine, and you must use IP addresses, I would say ping the name of the SQL Server, and see what comes back. Then ping that address from your local machine to make sure that you can get there.
As for how to connect to the DB itself, you will have to talk to their administrator. Ideally you should get a read-only login for the particular database you want to connect to. Many small shops use the sa login for all of their apps, but that is not very secure.
I had tried creating a new datasource using the SQL server machine name while connected via terminal session to the webserver. I get an error:
SQL Server Error: 53
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionOpen (CreateFile()).
SQL Server Error: 6
[Microsoft][ODBC SQL Server Driver][Named Pipes]Specified SQL Server not found.
I feel your pain on IP addresses in code, but I only want it to try to create a datasource on my home machine, since creating a datasource using the machine name doesn't seem to be working. Pinging the SQL box from the webserver console just gets me an internal network IP; a ping of that IP from my home machine (with terminal session running) times out.
In any event, using an external IP, if it exists, would seem preferable to a machine name for my purposes, because it means I don't have to keep a remote desktop session open 24/7 for the next month.
I have no problem connecting to the DB when using Enterprise Manager from the webserver console---it's set up to use Windows authentication---I believe I could ask for & receive SA access if it were necessary though.
When you get to the second screen of the ODBC Configuration (where it asks for a user and password), click on the Client Configuration button. See if you can change the NetLib to TCP/IP. Sometimes the NetLibs can be a little funny about actually finding a server. This would be on the client's webserver, of course.
I did try that, in spite of not knowing what the heck I was doing---figured I couldn't break what wasn't work in the first place. No love, though---thanks for the suggestion.
My client is using <a href="http://www.neoteris.com/products.html">Neoteris</a> to manage remote sessions. I don't know much about the technical details of how it works (and because their support pages require a customer id and password, it seems they don't WANT me to know) but I found a diagnostic button to click and I can see where it is mapping a number of machine names on their network to IP addresses in my home network's internal space. I see the webserver machine name there; I don't see the SQL box machine name.
I broke down and emailed my contact to ask if they can set up remote access authorization to the SQL box too---I still don't like the notion of having to keep the Neoteris session (based in a java applet in a web browser) running 24/7. It's gonna be fun the first time my DSL hiccups and the client calls me all "I can't connect to the test site" and I'm on the other side of town---but it would be a solution.