March 20, 2012 at 8:05 am
Scenario:
I have a sproc that creates a server side trace using sp_Trace_Create, and its trying ot create the trace file in the SQL Server directory.
I have admin permissions on the server.
When i run the sproc i get this error:
Windows error occurred while running SP_TRACE_CREATE. Error = 0x80070005(Access is denied.).
Msg 19062, Level 16, State 1, Procedure sp_trace_create, Line 1
Could not create a trace file.
if i grant the sql server service account read/write permissions on the directory, the sproc runs successfylly.
Why is the sp_trace_create running under the sql server context, and not mine?
UPDATE: found this line in Books Online for sp_trace_create:
For sp_trace_create, the SQL Server service account must have Write permission on the trace file folder. If the SQL Server service account is not an administrator on the computer where the trace file is located, you must explicitly grant Write permission to the SQL Server service account.
Guess that explains it. any reason why it does not run under the context of whoever is executing the sproc ( which could be the sql account, agent account or any user)?
March 20, 2012 at 8:55 am
Because it is not you writing the file it is SQL. There are several instances of this such as backups. The backup itself is generated by the SQL server in its context not by the user calling the backup.
There are few things (if any I can think of) that run in the context of the calling user when it reaches outside of SQL. I am guessing this is because if you come in with a SQL Login it would have to execute different code than if you came in with a windows user.. Just a thought..
CEWII
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply