Making use of other fixed server roles other than sysadmin

Are there a lot of folks out there that make use of other fixed server roles
other than sysadmin. ? Never really seen a strong use for ever using themI've seen use of both the securityadmin and processadmin
roles, although rarely. I tend to control all access to
the server as either developer needs (DDL level
security), enduser needs (DML level security) or DBA
needs (sysadmin).
It looks like Yukon is going to include more fine-grained
permission assignment, so I'd imagine this would be an
area to revisit once it is released -- and no, I have no
idea when :)
My 2 cents, hope it helps.
>--Original Message--
>Are there a lot of folks out there that make use of
other fixed server roles
>other than sysadmin. ? Never really seen a strong use
for ever using them
>
>.
>|||I agree with James... Most small shops have a single or two dbas, and
everybody does everything... But in a large company ( I work in an area
where there are some major banks), there may be 30-50 dbas. There is so much
work that each dba is assigned a specific task. They then use the other
server roles to give the minimum permissions...
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:OKHLc6OzDHA.2156@.TK2MSFTNGP09.phx.gbl...
> Are there a lot of folks out there that make use of other fixed server
roles
> other than sysadmin. ? Never really seen a strong use for ever using them
>|||On Sat, 27 Dec 2003 18:59:27 -0800, "Hassan" wrote:
>Are there a lot of folks out there that make use of other fixed server roles
>other than sysadmin. ? Never really seen a strong use for ever using them
Where the application is going to be maintained by people who should not
typically have sysadmin access, but need to be able to add logins, you
can grant these people securityadmin, and then also db_securityadmin in
the application's associated database(s).
cheers,
Ross.
--
Ross McKay, WebAware Pty Ltd
"The lawn could stand another mowing; funny, I don't even care"
- Elvis Costellosql

make more space available for store proc editing

A suggestion for the Microsoft folks (those who have access to them can
forward?):
when editing stored proc from EM, the screen estate is vastly wasted. Some
of us don't care, some of us do care about this. For those who don't care,
they should not have much to object the idea of making more screen space
accessible. So if you folks in the future could reduce the blank space and
convert it to space displaying code, I am one of those who would applaud.
Quentin> when editing stored proc from EM, the screen estate is vastly wasted.
Some
> of us don't care, some of us do care about this.
Use Query Analyzer. Press F8, you can right-click a stored procedure and
hit Edit (or script to new window as create, if you like to drop/create all
your objects).
You can even run only sections of code from this interface (by highlighting
only the relevant portions), test and debug, and - wow - you aren't stuck in
modal mode, so you can actually look at other stored procedures, other
servers, tables, etc. while you are working on a proc.
Enterprise Manager is not really meant for development, but more for
Enterprise Management, hence the name.
A|||Thanks Aaron.
I'm thinking making more space available for EM stored proc editing does not
hurt anyone and some benefit from it.
Quentin
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:OQdu1L4VDHA.1784@.TK2MSFTNGP10.phx.gbl...
> > when editing stored proc from EM, the screen estate is vastly wasted.
> Some
> > of us don't care, some of us do care about this.
> Use Query Analyzer. Press F8, you can right-click a stored procedure and
> hit Edit (or script to new window as create, if you like to drop/create
all
> your objects).
> You can even run only sections of code from this interface (by
highlighting
> only the relevant portions), test and debug, and - wow - you aren't stuck
in
> modal mode, so you can actually look at other stored procedures, other
> servers, tables, etc. while you are working on a proc.
> Enterprise Manager is not really meant for development, but more for
> Enterprise Management, hence the name.
> A
>|||> I'm thinking making more space available for EM stored proc editing does
not
> hurt anyone and some benefit from it.
I understand, however I'm suggesting a workaround, because you're not going
to see any changes to the client tools in SQL Server 7.0/2000.