Re: Troubleshoot connecting client to SQL Server instance on a server
- From: "Norman Yuan" <NotReal@xxxxxxxxxxx>
- Date: Wed, 31 Jan 2007 15:44:57 -0700
Norman,
Thanks again for your efforts to help. I seem to have found the
problem. Obviously no one would be able to troubleshoot a problem as
directly as the particular user, and as has been mentioned, I'm sure
there is an endless list of problems that could reproduce this
particular connection error. Even though it must not seem apparent, I
actually have been "reading the book" on SQL Server Express '05, as
long as it's been out. I would consider myself to be the prototypic
target user - the small office on a budget that would not support a
full-time IT consultant. Although I have not found the introduction
to SSE to be "easy," I've been determined enough to keep
troubleshooting such issues until -with significant help from
contributors like you and Sylvain- the particular snag can be
resolved.
Here's what I learned:
As I mentioned, I believed the test client user was succsessfully
logged on to the Windows server itself (evidenced by such things as
the network status stating that the client was connected, the client
being able to send and receive Outlook/Exchange email messages with
another test client, the client being able to explore shared folders
elsewhere on the network, etc.).
However, those who are professional network administrators would
probably see the problem coming when I explain that I had set up the
test client user on a computer that had previously been used as a
stand-alone desktop. In retrospect I should have discerned that a
type of "hybrid" user account resulted. Even though the startup logon
screen changed from the stand-alone desktop "Welcome" screen to a
"Press Control-Alt-Delete" screen leading to the network logon, the
previous (before client setup) desktop and files were retained.
It seems you have a client/server domain network.In this case all user
account is centrally managed by domain controller. However, a user may still
be able to log onto his computer LOCALLY. A local user account is not
recognized by other computer. So, if you use Windows authentication in SQL
Server, the Windows user account used to access SQL Server must be
recognizeable for the SQL Server, that is, the Windows user account should
be either a domain user account, or local user account on the computer where
SQL Server runs. Then you map SQL Server logins to this type of user
accounts, and assign appropriate access to different databases on the SQL
Server. After that, a user logs into his computer (using a domain account,
or a local account to log in the SQL Server computer) will has expected
access to the SQL Server database(s) without needing to send
username/password to SQL Server. This is Windows Authentication mode of SQL
Server.
I established a new "clean" user on the client computer, which was
then able to be recognized as an available network user by SQL Server
Express in Mgmt Studio on the SBS Server. Subsequently I was able to
successfully log on to the SSE instance from the client (both via Mgmt
Studio on the client and via the ADP).
What I'm surprised to see in the many connection-related postings you
commented on are the recommendations to abandon Windows-authenticated
logons for mixed mode or SQL Server logons. If Windows-authenticated
logons are in fact the most secure, it would seem that their use would
be commonplace and relatively uncomplicated to establish.
These kind of talks on using SQL Server security are usually regarding SQL
Server access from web application. Because web application users are not on
the network domain where the SQL Server runs usually. When you use SQL
Server security, you need to pass username/password through the wire, you
need some means to hide it from hacker. Even you use SQL Server inside your
network, you need either store username/password with the applications
safely (added compexity), or you ask user to enter it each time to access
data and ask them to remember it. However, if you use Windows security, user
only need to log on to his computer. Afterward, his user identity is
recognized anywhere with the network.
As I mentioned, one of my greatest frustrations with the (to-be-sure
affordably priced or even free) MS products is the simplicity of a
particular concept against an extraordinarily difficult or snag-prone
execution. My next project is to continue to try to make a linked
server work to connect SQL Server Express to Exchange. So far,
following the MSDN examples and reading the related posts has not
yielded a working result. I would think that tapping into Exchange/
Outlook would be considered one of the most basic operations for a SQL
Server user. If any readers have insight on this and would be willing
to help me, please reply.
I do not see SQL Server has somethign to do with Exchange/Outlook. You can
send email from one computer to the other, that may prove that your network
is through for email. But you may still have trouble with SQL Server, if it
is not set up correctly.
.
- Next by Date: Re: Access 2007 ADP and SQL
- Next by thread: Re: Access 2007 ADP and SQL
- Index(es):
Relevant Pages
|
