Thanks Q*bert,

That helps out a bunch! I really appreciate the time you have taken to explain
everything. I'll have the firewall ports checked out. I think since it's
a new server it might not have been added to the appropriate access control
list yet - allowing the passthrough you mention.

Again, I appreciate the help.

"Q*bert" <> wrote:
>I assume your IIS server is sitting in the DMZ and that your SQL server

>sitting inside your network. Is it possible that your Firewall is not setup
>to allow access through the appropriate ports?
>A typicall secure network would have Diagram like the below
> INTERNET (The World)
> |
> |
> IIS, Terminal Server, Others } DMZ (Demillitarized zone
> | }
>Public Address Scheme (!10.x.x.x and !192.168.x.x)
> |
>Private address Scheme (10.x.x.x or 192.168.x.x)
> SQL Server
> Domain Controller
> Terminal Servers etc
> ETC..
>Now based on that design, your IIS server would need to be allowed through
>the Internal Company Firewall for the appropriate ports, have to look them
>up on the web if you don't know. Or, allow all(requests from the IP address
>of your IIS Server (bad design as if anyone hacks your IIS server, they

>then gain access to your internal network(all ports) allowing Just port
>80 and the one for SQL connections would be enough))
>Named Pipes, in this case I believe, will not work as it would have to pass
>through the firewall. Since it(I believe) is a non-routable protocol, it
>would not be able to get through.
>If your network design is not this complex, then Check to see if there the
>SQL servers and IIS server are part of the appropriate domains. If not,
>fix that. Some simple things to check are
>1) can your IIS server PING your SQL server(s), if not you have a network
>problem somewhere
>2) If they can ping, can you authenticate to them using local user accounts?
>3) if that works, are the ports on the server setup to allow incomming traffic
>from all hosts?
>4) Is there a problem with your configuration of the LMHosts file?
>Last, if the web sever is expected to get lots of traffic (more than 1000
>users at a time), you might consider DSN-less connections over the ODBC

>as you will have a slight performance gain around the 1000th user. This
>of course assumes you can use DSN-less connections.
>Don't know if this helped or not. But at least I made you think about the
>security of your network and the data on it.
>"Terry" <> wrote:
>>We have just installed a new server that is supposed to function primarily
>>as an IIS server. I am experiencing a few problems configuring ODBC connections
>>from this IIS server to our database servers. I am able to make an ODBC
>>connection to an old SQL 6.5 box only after mapping a drive from this new
>>IIS server to the drive where the 6.5 MASTER db resides, and I cannot connect
>>at all to our new 2000 SQL box. The error I'm getting is
>>"Connection failed:
>>SQLState: 01000
>>SQL Server Error: 1326
>>[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionOpen (CreateFile()).
>>Connection failed:
>>SQLState: 08001
>>SQL Server Error: 1326
>>[Microsoft][ODBC SQL Server Driver]Client unable to establish connection"
>>We are running two named instances on the new SQL 2000 server without any
>>default instance installed. I have tried to connect both with named pipes
>>and TCP/IP.
>>How do you update the SQL Server ODBC driver? It may be out of date.
>>Does anyone have any ideas what may be causing this problem?