August 26, 2007 at 5:49 am
Hi, all:
I've been up the past five hours wrestling with an oddity, which while it is now functionally resolved, has left me curious. I'll describe what occurred, and then I have a simple question.
I fitted a new, faster development machine, and installed all the tools, VS 2003 & SQL Server 2005 being the two specific to what occurred. I then migrated an existing application (ASP.NET web application, still in .NET 1.1) and configured it; along with its database. This is a standalone development box, connected to the network for the sole purpose of Internet. All went well, but an attempt to run the application resulted in the dreaded "SQL Server does not exist or access denied" message. I checked everything, comparing it to the still functional old machine -- and found nothing obviously wrong. From several other applications the exact same connection string worked. Finally, after much stumbling around and muttering I resolved the issue by making a strangely simple change to the connection string: Server=(local); became Server=.; with the rest of the string unaltered. And everything worked.
Now, my question is this: What is the underlying reason it worked? What does the use of the period imply that the (local) does not? I am curious largely because it seems a peculiar occurrence since I had this exact configuration working on the old machine.
Anyhow, any insight is appreciated. I searched but either the long night or the small brain failed me in my quest for an answer.
Thanks.
August 28, 2007 at 7:38 am
Frank,
I'm not exactly sure what the "." implies for the server but I think it probably swtiches to a different connection type (i.e. shared memory, named pipes, etc.). It's likely that your new installation has some connection type turned off that was turned on on the other machine. TCP/IP perhaps?
A Bit more information here: http://weblogs.asp.net/jgalloway/archive/2005/12/02/432062.aspx
August 28, 2007 at 8:29 am
"." as I recall implies localhost or 127.0.0.1 (the tcp-ip lookback address). Odds are the reason (local) failed however is becase named pipes are disabled on the server setup.
August 28, 2007 at 9:31 am
I will certainly check named pipes. I thought I had the two identically configured, but certainly I could have missed a click.
What I find odd is that almost all references suggest "." is the same as "localhost," yet one would wonder why if that is the case neither "localhost"nor "127.0.0.1" worked.
This is one of those great mysteries I wish I had time to investigate futher. I will certainly post again if I discerned a difference, or resolve this.
Thanks again for the replies.
August 28, 2007 at 9:49 am
I didn't notice you mentioning running the surface config tool? seems to get me tripped up a lot when I am setting up new test victims. Without that - I don't think IP connections (even local) work. It only allows local only connections through "shared memory calls" if I remember.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 28, 2007 at 9:59 am
I did run it (though I too have forgotten that step more than once); and I just checked to find on both boxes TCP/IP and named pipes remains activated.
I wonder if it could be an MDAC issue?
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply