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

[Radu]

Hi. Thru a sproc, I drop & re-create some temp tables.

When I call that sproc from the client, though, I cannot drop the
tables.
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_TAB LE" (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_Gene ral_CP1_CI_AS NULL ,
...........
[Stuff] [varchar] (20) COLLATE SQL_Latin1_Gene ral_CP1_CI_AS NULL

) ON [PRIMARY]'
Exec (@StrSQL)

Set @StrSQL = 'GRANT SELECT , UPDATE , INSERT , DELETE ON [dbo].['
+ @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:
_______________ _______________ _______________ __
CREATE PROCEDURE _TEST AS

DROP TABLE [dbo].[SomeTable]

RETURN
_______________ _______________ _______________ __

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
SomeTable"

The table has been created thru "CREATE_TAB LE", above

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

Thanks a lot,
Alex.

[Simon Hayes]

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):

http://www.sommarskog.se/dynamic_sql.html#Cre_tbl

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.

Simon