MSDE 2000 with Access 2003: The First steps.
1) install MSDE from Office CD (need to locate in MSDE directory by browsing and start it manually. Read KB article 319930 first);
2) when installing, need to specify "sa" (system admin) password which is not (does not have to be anyway) the same as Windows Administrator's password. It is required in order not to leave sysadmin password blank which would leave a security hole;
3) if you are using all the correct switches with the 'setup' command, the mixed login mode will be allowed. The mixed login mode lets you login from non-admin account by using MSDE login. I did not use any switches so had to make the adjustments in the r
egistry. Very easy, but I still had to locate the required key which was not where it is supposed to be judging from KB article 319930, but quite near it.
4) restart and check that 2 new services are running: MSSQLSERVER and SQLSERVERAGENT.
5) restart the PC and log in under (Windows) administrator account (does not need to be THE "Administrator", just any account with admin privileges)
6) test the connection to MDSE by going to command line, typing "osql -E" (no " needed). You should see ">1" which means MDSE is running.
7) Now this is the $100 trick: type "sp_addlogin [BUILTIN\POWER USERS]", <ENTER>, "GO". wait for some reaction (something like 2 rows affected)
8) Here comes another $100 trick: type "grant all", <ENTER>, "to [BUILTIN\POWER USERS]", <ENTER>, "go".
Now you can go back to your every day Windows login (I assume you are using an account from Power Users group, aren't you?), start Access, create a new .adp file and connect your Access .adp file to MSDE using "Trusted Connection" or "Use Windows NT integ
rated security".
Oh by the way you can type "exit" from command line to stop your connection to MSDE when you feel like.
You can also submit commands and scripts via OSQL directly from the command
line. I thought from your previous post that you were trying to 'assign
(SQL) sysadmin permissions to a newly created (SQL) account.' I.e., your
SQL account was already created and you were trying to put it in the
sysadmin server role. By the way,
$50 Discount - GRANT grants database-specific permissions to users. So if
you have more than one Database, you need to use GRANT on all databases and
database objects you want the user to have access to.
$0.02 worth - sp_addrolemember and sp_addsrvrolemember adds users to
server-wide roles, like "sysadmin." GRANT is database object specific, so
it works only on individual databases and database objects (tables, etc.)
Cheers,
Michael C.
"Lolik" <Lolik@.discussions.microsoft.com> wrote in message
news:BDFB3614-78ED-4DB2-8468-7C78073A7906@.microsoft.com...
> Finally got to the point where I can connect to MSDE from Access. If you
are setting up MSDE for the first time, you may find a couple useful points
in the following.
> MSDE 2000 with Access 2003: The First steps.
> 1) install MSDE from Office CD (need to locate in MSDE directory by
browsing and start it manually. Read KB article 319930 first);
> 2) when installing, need to specify "sa" (system admin) password which is
not (does not have to be anyway) the same as Windows Administrator's
password. It is required in order not to leave sysadmin password blank which
would leave a security hole;
> 3) if you are using all the correct switches with the 'setup' command, the
mixed login mode will be allowed. The mixed login mode lets you login from
non-admin account by using MSDE login. I did not use any switches so had to
make the adjustments in the registry. Very easy, but I still had to locate
the required key which was not where it is supposed to be judging from KB
article 319930, but quite near it.
> 4) restart and check that 2 new services are running: MSSQLSERVER and
SQLSERVERAGENT.
> 5) restart the PC and log in under (Windows) administrator account (does
not need to be THE "Administrator", just any account with admin privileges)
> 6) test the connection to MDSE by going to command line, typing "osql -E"
(no " needed). You should see ">1" which means MDSE is running.
> 7) Now this is the $100 trick: type "sp_addlogin [BUILTIN\POWER USERS]",
<ENTER>, "GO". wait for some reaction (something like 2 rows affected)
> 8) Here comes another $100 trick: type "grant all", <ENTER>, "to
[BUILTIN\POWER USERS]", <ENTER>, "go".
> Now you can go back to your every day Windows login (I assume you are
using an account from Power Users group, aren't you?), start Access, create
a new .adp file and connect your Access .adp file to MSDE using "Trusted
Connection" or "Use Windows NT integrated security".
> Oh by the way you can type "exit" from command line to stop your
connection to MSDE when you feel like.
|||$0.02 worth - sp_addrolemember and sp_addsrvrolemember adds users to
server-wide roles, like "sysadmin." GRANT is database object specific, so
it works only on individual databases and database objects (tables, etc.)
__________________
Do not underestimate your input Michael!
Guess I should run sp_addsrvrolemember too. Still after having used GRANT as above I was able to create a new SQL database and connect to it, at the time a new Access .adp file was set up.
The $50 tag referred to using [BUILTIN\POWER USERS] as a login. Could not find it mentioned anywhere. Maybe it is obvious to everyone but me but figuring out what [Corporate\Bobj] is in XP language was not straightforward to me at all.
|||Yes, you can grant User Groups access rights to your SQL Server
One ofthe benefits of using Integrated Security for your SQL Server logins. The
built-in server roles, like sysadmin grant general permissions server-wide,
and include various other little niceties. Since your user created the 2nd
database, that user is the database owner (dbo) for that database, so that
user will have all the rights associated with that database. Server Roles
make it a little easier to admin multiple databases.
Cheers,
Michael C.
> Do not underestimate your input Michael!
> Guess I should run sp_addsrvrolemember too. Still after having used GRANT
as above I was able to create a new SQL database and connect to it, at the
time a new Access .adp file was set up.
sql
