Hi -
I may not sound desparate, but I really am. I have spent many days now trying to install and re-install Microsoft SQL 2005 Express. I still cannot connect to the database! I have read this forum and tried various suggestions, like setting the remote connections and TCP/IP + Named Pipes. Still doesnt work!
The environment is Dell Dimension 24000 (I86) with WinXPPro.
Out of desparation, I downloaded and installed Oracle 10g XE. It works just fine !
My question is: Does the Oracle database server interfere with connecting to the Microsoft SQL 2005 Express server ?
Also, I notice that there are an awful lot of questions posted on this Forum concerning just getting your software up and running. Are there that many stupid folks out there like myself, or has this application been released prematurely ?
hi,
PussyFoot wrote:
Hi -
I may not sound desparate, but I really am. I have spent many days now trying to install and re-install Microsoft SQL 2005 Express. I still cannot connect to the database! I have read this forum and tried various suggestions, like setting the remote connections and TCP/IP + Named Pipes. Still doesnt work!
The environment is Dell Dimension 24000 (I86) with WinXPPro.
Out of desparation, I downloaded and installed Oracle 10g XE. It works just fine !
My question is: Does the Oracle database server interfere with connecting to the Microsoft SQL 2005 Express server ?
I do not think so, but Mike probably knows better...
Also, I notice that there are an awful lot of questions posted on this Forum concerning just getting your software up and running. Are there that many stupid folks out there like myself, or has this application been released prematurely ?
I do think it's all so "complicated" becouse of the features exposed by SQLExpress it self.. so, installing as default as a named instance can perhaps provide problems becouse the SQLBrowser service is not up and running (just usual) and this will prevent remote connections, as the "secure" setting of disabling remote connections (both TCP/IP and named pipes) to be "opend" via Surface Area Configuration applet... then often the product is "used" in User Instance "mode", but User Instances are not enabled as well by default... you can then add Windows Firewall (or other firewall as well) to the potential problems as well..
the "secure" phylosophy is secure, but sometimes provides some headaches to use the product as desired becouse of all the underlying "settings to be "set"...
just my $0.02
regards
|||Andrea -
A very diplomatic response indeed.
But all I am concerned with at this point is Step 1, getting the SQL Server 2005 Express Management Studio to connect to the SQL Server 2005 Express. That seems pretty basic to me. On another machine at my office, without any fussing around, the same installation appears to be in working order.
Any suggestions on what might be wrong with my home installation?
#1 - Home environment: Dell Dimension 2400 (I86), WinXPPro, only manual dial-up connection to Internet
#2 - Work environment: Dell Optiplex (I86) on corporate network with many other network servers
1 doesnt connect, 2 connects without any fussing around.
What's the difference and how might I troubleshoot #1 ?
Please advise. Thanks. Mike
|||Hi Mike,
There should be no conflict or problems by installing Orcacle 10g XE and SQL Express on the same machine.
As far as the Express connection problem, it would help to know the exact error you are getting.
It seems from the configuration you've listed that you are just trying to connect locally, i.e. Management Studio is on the same computer with SQL Express. Is that right? I typically don't have any problems making local connections since the default installation includes everything you need to be able to make a connection on the local computer. The problem I typically see people have is getting the instance name right.
Assuming you didn't change anything during install, and that you are connecting locally, we can try a direct connection from SQLCmd just to rule out anything wrong with SSMSE. Open a command window and type the following at the prompt:
SQLCmd -S .\SQLEXPRESS -E -Q "SELECT @.@.Version"
This should return information about the version of SQL Express you are running. If this works, then SQL Express is running and you can connect to it using Shared Memory, the default protocol for local connections. If this doesn't work, reply with the exact text of the error message.
If you are connecting from a remote computer, you should make sure you have everything configured correctly to allow remote connections. You can find a link in the FAQ at the top of this forum to information about configuring SQL Express for remote connections. There are a number of things that must be configured to allow remote connectons to SQL Express.
I think it's worth exploring a bit why SQL Express is designed this way. It might seem that you should just be able to connect to SQL Express through the network, but it's important to understand what that really means to you. First you need to understand a term we use called "Surface areas of attack." In short, the surface area of attack for a computer is sum total of the ways an evil doer can gain access to your computer. The more you reduce the surface area of attack, the lest risk you have. As an example, consider a house: each door and window is a posible means of attack where a burgler could enter, the more doors and windows you have the larger your surface area and the greater your risk. The ability to connect to SQL Express from a remote computer is like adding another door to your computer, SQL Browser is like a window. Now doors and windows are important to a house, and remote connections and SQL Browser are important to SQL Express, but if you don't need them, you shouldn't have them. We've made the decision as part of our Secure by Default efforts that we will not arbitrarily increase the surface area of attack for your computer. There are millions of people out there who are using SQL Express only to store local data, they do not need the extra doors and windows created by allowing remote connections. Being Secure by Default means that users have to make the explicit decision to increase the surface area of attack, not the other way around.
I am looking at ways to make this choice more obvious to you when you install, so that stuff like this doesn't require a set of extra steps after installation, but can be accomplished more easily during installation. (But it will still be off be default.) Hopefully this at least gives you some insight into why we work the way we do.
Mike
No comments:
Post a Comment