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

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_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_C
P1_CI_AS NULL ,
..........
[Stuff] [varchar] (20) COLLATE  SQL_Latin1_General_C
P1_CI_AS NULL

) ON [PRIMARY]'
Exec (@StrSQL)

Set @StrSQL = 'GRANT  SELECT ,  UPDATE ,  INSERT ,  DELETE  ON [dbo].	
1;'
+ @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_TABLE", above

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

Thanks a lot,
Alex.

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