Re: Installation OK, but can't connect
From: Andrea Montanari (andrea.sqlDMO_at_virgilio.it)
Date: 03/08/04
- Next message: Andrea Montanari: "Re: SQL DB to MSDE DB"
- Previous message: Keith: "SQL DB to MSDE DB"
- In reply to: Daniel Strigard: "Re: Installation OK, but can't connect"
- Next in thread: Daniel Strigard: "Re: Installation OK, but can't connect"
- Reply: Daniel Strigard: "Re: Installation OK, but can't connect"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 8 Mar 2004 12:40:27 +0100
hi Daniel,
"Daniel Strigard" <anonymous@discussions.microsoft.com> ha scritto nel
messaggio news:8bf401c404ec$46a61920$a401280a@phx.gbl...
> Hi again.
>
> Now I've managed to get a connection to the server and
> created an access database.
> Thanks for the help Andrea!
=;-))
> But now I have some further questions.
>
> My connection string looks like this at the moment:
> "User Id=sa;Data Source=KBAWS46\NetSDK;Password=pwd"
>
> When my program is run on another computer, how will
> things work? I've named a user id, a data source and a
> password that won't exist on that computer.
SQL Server authentication is "client" independent.... that's to say you can
connect with the same credential from any client on you lan
> Won't I have to use another, more general, way to connect
> to a database, without specifying user and password?
this is a good idea, and is known as trusted WinNT security atuthentication
mode =;-)
with security_admin of sysadmin privileges, you have to grant login to your
trusted WindowsNT users and/or groups...
you can read more info at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/architec/8_ar_da_79lt.asp
and following pages...
> The data in the database isn't classified in any way, and
> I don't mind anyone else fiddling with it, so if SQL
> Server don't need a user and password, I'm won't want one.
> And the specifying of my computer name must surely cause
> trouble when using another computer.?
> Could someone please explain how this works?
SQL Server always requires a little credential in order to first log in, and
then access data in the databases... this is a 2 phase authentication:
-) in order to access the server, it's instance name must be specified [or
(local) can be specified for local connections] so this will cause no
trouble at all but is a requirement =;-)
as already said, you can choose between 2 authentication modes: WinNT
(trusted) connections or SQL Server authenticated connections... the latter
always requires full user's credential such as "User Id=sa;Password=pwd",
the password can be NULL sot it must not be specified, but I strongly advise
you always to ensure strong passwords are present....
WindowsNT authentication, on the contrary, does not requires user's
credential becouse it's directly provided by Windows via the logins'ID (sid)
, which authenticate user's login at the windows login step...
SQL Server only needs to verify that the corresponding login and/or group is
granted to log on the instance...
this is the first phase....
the second phase regards database access...
each login, both WindowsNT and SQL Server authenticated, must be granted
database access rights in order to "access" database's objects (only logins
part of sysadmin server role are not required to)
this is performed via sp_grantdbaccess system stored procedure (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_sp_ga-gz_290z.asp )
this procedure maps the named login to a database user via the login SID and
permission are resolved via the JOIN of sysusers.sid (in the user database)
and syslogins.sid (in the master database)....
from BOL:
".....
A user is essentially the way SQL Server resolve permission to access
databases and database objects.
A user ID identifies a user within a database. All permissions and ownership
of objects in the database are controlled by the user account. User accounts
are specific to a database; the xyz user account in the sales database is
different from the xyz user account in the inventory database, even though
both accounts have the same ID. User IDs are defined by members of the
db_owner fixed database role.
A login ID by itself does not give a user permissions to access objects in
any databases. A login ID must be associated with a user ID in each database
before anyone connecting with that login ID can access objects in the
databases. If a login ID has not been explicitly associated with any user ID
in a database, it is associated with the guest user ID. If a database has no
guest user account, a login cannot access the database unless it has been
associated with a valid user account
When a user ID is defined, it is associated with a login ID. For example, a
member of the db_owner role can associate the Windows NT login NETDOMAIN\Joe
with user ID abc in the sales database and user ID def in the employee
database. The default is for the login ID and user ID to be the same.
A user in a database is identified by the user ID, not the login ID. For
example, sa is a login account mapped automatically to the special user
account dbo (database owner) in every database. All the security-related
statements use the user ID as the security_name parameter. It is less
confusing if the members of the sysadmin fixed server role and the db_owner
fixed database role set up the system such that the login ID and user ID of
each user are the same, but it is not a requirement.
....."
hth and please excuse my poor english
-- Andrea Montanari (Microsoft MVP - SQL Server) http://www.asql.biz/DbaMgr.shtm http://italy.mvps.org DbaMgr2k ver 0.6.0 - DbaMgr ver 0.52.0 (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual interface) --------- remove DMO to reply
- Next message: Andrea Montanari: "Re: SQL DB to MSDE DB"
- Previous message: Keith: "SQL DB to MSDE DB"
- In reply to: Daniel Strigard: "Re: Installation OK, but can't connect"
- Next in thread: Daniel Strigard: "Re: Installation OK, but can't connect"
- Reply: Daniel Strigard: "Re: Installation OK, but can't connect"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
