By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,950 Members | 1,032 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,950 IT Pros & Developers. It's quick & easy.

Howto setup my user in order to grant him the drop privilege

P: n/a
Hi. Thru a sproc, I drop & re-create some temp tables.

When I call that sproc from the client, though, I cannot drop the
I need to allow the user, say "Alex", to drop/create tables (actually,
that would be DDL). Which role should "Alex" assume ? How do I do that

I run the following sproc named, say, "CREATE_TABLE" (SNIP):
__________________________________________________ __________________
Set @StrSQL = 'if exists (select * from dbo.sysobjects where id =
object_id(N''[dbo].[' + @TableName + ']'') and OBJECTPROPERTY(id,
N''IsUserTable'') = 1) drop table [dbo].[' + @TableName + ']'

Exec (@StrSQL)

Set @StrSQL = 'CREATE TABLE [dbo].[' + @TableName + '] (

[GROUP] [varchar] (6) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[Stuff] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NULL

Exec (@StrSQL)

+ @TableName + '] TO [Alex]'

Exec (@StrSQL)
__________________________________________________ __________________

As you can see, it is dynamic, because I need to repeat it for many
@TableName values - that means, further more, that I will be executing
this in the context of the current user, Alex, and therefore I have to
give Alex rights to both executing the sproc and to the tables referred
to by the sproc, as specified by @TableName.

I created a _TEST sproc which contains only the following:

DROP TABLE [dbo].[SomeTable]


When I execute it from the client, thru ADODB, on user Alex, I get
"User does not have permission to execute this operation on table

The table has been created thru "CREATE_TABLE", above

Please help, I have to finish this tomorrow, and I'm under tons of

Thanks a lot,

Sep 27 '05 #1
Share this Question
Share on Google+
1 Reply

P: n/a
This is usually not a good solution - if you allow users to drop and
create tables, it's very difficult to control your your database. And
if users need to dynamically create tables owned by dbo, they will need
to be in the db_owner role, which is generally not desirable.

A better option would be to have a single permanent table with the
login or SPID as part of the key (you can use a view to show each user
only their own data), or perhaps use temp tables, for which you need no
special permissions. See here for comments on the disadvantages of
dynamically creating tables (and the rest of the article for comments
on dynamic SQL in general):

If this isn't helpful, I suggest you give some more details about what
you're trying to achieve, and why you want to create and drop tables
dynamically - someone may be able to suggest an alternative approach.


Sep 28 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.