"TRUNCATE TABLE" in a sproc w/locked-down user

Hullo folks, I'm having what I assume is a fairly mundane security issue.

I have a SQL login that I am trying to restrict as much as possible. This account's sole goal in life is to hit the server, return some usage statistics, then truncate the table it received the statistics from. I would like to refrain from granting this login permissions on the physical target table if possible.

Usually I can wrap up "protected" operations in a stored procedure, then grant exec permissions for my user and I'm good to go. However, TRUNCATE TABLE gets cranky with me when I attempt the above method. I suspect that has to do with the fact that TRUNCATE TABLE is effectively modifying the table itself as opposed to merely deleting data.

Is it possible to grant this login ONLY execute permission on a stored proc that TRUNCATE's tables without giving the user any physical permissions? Am I going about this the wrong way?The only people who can use 'truncate' are the table owner, sysadmin, db_owner, and db_ddladmin; so if you have a user whose permissions are severely restricted I would not think 'truncate' would work, or if it would it would be a phaff to set up.

Why not just DELETE FROM, or use a temp table to create the statistics and return them?|||This is effectively what I ended up doing after making the same permissions determination. I had my heart set on Truncate do to the nature of the process itself, but I was able to work around the restriction using DELETE FROM and a local scheduled maintenance job.|||Is there a way he can call an osql command via xp_cmdshell that connects with a trusted connection that can truncate the table ? I tried some stuff with a server link to itself, but cannot truncate table link.db.owner.table, same goes with openquery (truncate not supported).|||That would present a larger security issue then outright granting the user required permissions. I definately don't want to expose trusted command line functionality to this login.

What I have now works, it's just not exactly the way I want it to. All of my research indicates that it will just have to be good enough as I cannot get around that pesky permissions requirement for TRUNCATE.|||In the past I have allowed a user to own a single table for a similar purpose. But that was for an import table, where the data was truncated, reloaded, diced up, and distributed to other tables. No other process even knew the table was there. It gets you out of having to have db_owner rights, but there is no other way around the requirement of owning the table.|||why dont you leave the table there and run a nightly process that truncates any table that had statistics grabbed from it

have an admin account run the nightly process, but the restricted user still gets their statistics

just a thought|||why dont you leave the table there and run a nightly process that truncates any table that had statistics grabbed from it

have an admin account run the nightly process, but the restricted user still gets their statistics

just a thought
That's the current working solution. The process runs a couple times a day, but same idea.

"Drop Table" at Stored Procedure

Hello folks,
i like to change a sql-skript to a procedure. The skript includes 20
statements like
select ... into #temp
and
drop table #temp
It runs as a batch if i use
drop table #temp
go
In order to change it to a procedure i change all "drops" to
drop table #temp;
but i can't create the procedure.
The SQL-Server error message was
'Es gibt bereits ein Objekt #Temp'
(translated 'Object #temp still exists')
This Message was shown five times and point to the Select-Staments (not to
all).
To move the drop - Statement direct before the select does'nt help to solve
this behaivor;
I have no idea to solve this problem.
Thanks in advance for any help.
NielsCREATE PROC mysp
AS
IF OBJECT_ID('TempTable') IS NOT NULL
DROP TABLE TempTable
"nieurig" <nieurig@.discussions.microsoft.com> wrote in message
news:045E2CDA-E8BF-4F55-8668-EC1B47139314@.microsoft.com...
> Hello folks,
> i like to change a sql-skript to a procedure. The skript includes 20
> statements like
> select ... into #temp
> and
> drop table #temp
> It runs as a batch if i use
> drop table #temp
> go
> In order to change it to a procedure i change all "drops" to
> drop table #temp;
> but i can't create the procedure.
> The SQL-Server error message was
> 'Es gibt bereits ein Objekt #Temp'
> (translated 'Object #temp still exists')
> This Message was shown five times and point to the Select-Staments (not to
> all).
> To move the drop - Statement direct before the select does'nt help to
solve
> this behaivor;
> I have no idea to solve this problem.
> Thanks in advance for any help.
> Niels
>|||It's a resolution issue. Consider naming the temporary table differently in
each create. The other option is to use dynamic execution, but such approach
involves many issues of its own.
BG, SQL Server MVP
www.SolidQualityLearning.com
"nieurig" <nieurig@.discussions.microsoft.com> wrote in message
news:045E2CDA-E8BF-4F55-8668-EC1B47139314@.microsoft.com...
> Hello folks,
> i like to change a sql-skript to a procedure. The skript includes 20
> statements like
> select ... into #temp
> and
> drop table #temp
> It runs as a batch if i use
> drop table #temp
> go
> In order to change it to a procedure i change all "drops" to
> drop table #temp;
> but i can't create the procedure.
> The SQL-Server error message was
> 'Es gibt bereits ein Objekt #Temp'
> (translated 'Object #temp still exists')
> This Message was shown five times and point to the Select-Staments (not to
> all).
> To move the drop - Statement direct before the select does'nt help to
> solve
> this behaivor;
> I have no idea to solve this problem.
> Thanks in advance for any help.
> Niels
>|||Thanks to Itzik and Uri !!
I will use the workaround with different names of my temp-table.
Have a nice day.
Niels