Re: deny truncate?
From: Keith Kratochvil (sqlguy.back2u_at_comcast.net)
Date: 10/14/04
- Next message: Rick: "Revoki the select permissions from the public role to the system t"
- Previous message: Dejan Sarka: "Re: msde security - windows mode?"
- In reply to: Bonj: "Re: deny truncate?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 14 Oct 2004 06:38:26 -0500
> I know, the thing is though, typing out all those statements could be
> regarded as work that isn't actually getting anybody anwhere that they
> couldn't be just put there by flipping a switch once.
Do you use source control? Do you store your stored procedures within
script files within that source control system? If so just add the
appropriate command to the stored procedure script files. Each time the
stored procedure is compiled (created) from the script file the appropriate
grant statement(s) will be executed.
> That's an option - it does need repeatedly calling, i.e. every time the
> database runs, though.
No, it needs to be called every time a stored procedure is dropped and
created (or newly created).
The sandbox approach would only apply for a very short development cycle.
You develop a table and a stored procedure in your sandbox. You get it
working. You get your DBA to create the table and stored procedure(s) as
dbo and you are done.
-- Keith "Bonj" <benjtaylor at hotpop d0t com> wrote in message news:OqrBpjVsEHA.2128@TK2MSFTNGP11.phx.gbl... > > They do not need to be dbo to execute a dbo owned stored procedure. Just > > have dbo issue > > GRANT EXECUTE ON dbo.YourProcName TO DeveloperNameGoesHere > > I know, the thing is though, typing out all those statements could be > regarded as work that isn't actually getting anybody anwhere that they > couldn't be just put there by flipping a switch once. There isn't a large > amount of developers, only 5 - in fact there's twice as many servers than > developers. I just thought if it was easy, then I could do it without too > much hassle. > > > You can easily create a stored procedure that issues the appropriate grant > > statements to the appropriate users on all stored procedures or on a > subset > > of stored procedures based on creation date or name. You decide what you > > need and create the supporting stored procedure to do it. > > That's an option - it does need repeatedly calling, i.e. every time the > database runs, though. > > > > > Giving users the ability to create tables....I would not give them dbo > > rights for this. I would let them play in their own "sandbox" by creating > > tables under their account. When their sand castle (or table) has been > > approved then dbocan create the table within the development environment > (as > > dbo). > > Don't get me wrong - I'm not the administrator. I'm a developer. > The 'sandbox' approach wouldn't really work though, because all too often > than not, we have to use the results of what another developer has done, > which is thus in his table. The 'users' of the system, as such, don't even > get to see SQL server. All they see are Excel sheets and graphs, and various > things such as crystal reports in pdf format, that are downloaded off the > servers. > > > > > > > > > > > Cheers > >
- Next message: Rick: "Revoki the select permissions from the public role to the system t"
- Previous message: Dejan Sarka: "Re: msde security - windows mode?"
- In reply to: Bonj: "Re: deny truncate?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
