Because of SOX we need to launch a modified C2-trace to monitor activities.

To be able to determine where to put the trace file, I've produced this sproc (because of reuse in the sox-backup-system)

Create Procedure sp_DBA_GetSOXTraceFileName
@TraceFileName nvarchar(245) OUTPUT
as
begin
set nocount on
/*
-- test execution
Declare @TraceFileName nvarchar(245)
exec sp_DBA_GetSOXTraceFileName @TraceFileName OUTPUT
print @TraceFileName
*/
SET @TraceFileName = ''
/*
* Get SQLServer Errorlog path
*/
Create table #tmpRegValues ([Value] varchar(50), [Data] varchar(1000))
insert into #tmpRegValues
exec master..xp_instance_regenumvalues N'HKEY_LOCAL_MACHINE', N'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\Parameters'

Select @TraceFileName = substring(Data, 3,datalength(Data) - charindex('\',reverse(Data)) - 2) + '\DBASOX' + '_' + replace(@@servername,'\','_') + '_' + replace(replace(replace(convert(char(16),getdate(),121),'-',''),' ','_'),':','')
from #tmpRegValues
where Data like '-e%'

if @@rowcount = 0
  raiserror ('DBASOX Unable to read SOX tracefilename !!', 16, 16) with log

DROP TABLE #tmpRegValues
end

Here's the problem :

If this proc is executed within a startup storedprocedure, it always raises the error 'DBASOX Unable to read SOX tracefilename'

Aparently it cannot read the registrykey at startup time

I've also tried to add a waitfor delay '00:00:05' in the actual startup proc
(residing both in master !) but that didn't help.

If I execute the proc in QA everything works fine

removing the Xp_regread Allowed Paths  also didn't help (KB 887165)

The server is SQL2000 SP4 + kb904659 + kb904660

For the moment I'll reside to storing this filename in an extra table in master, so the startup sproc for the sox-trace can be kept standard for all servers.

     Jul 13  

Sometimes this is me

Because we always have SQLAgent running, I've just implemented an extra job to check and launch the sox-trace proc.

This job is scheduled to start whenever sqlagent starts.

I've kept the startup sproc marked as startup proc for when this issue gets fixed.

     Jul 13  

Sometimes this is me

What's different in the OS / Server configuration between your QA environment and your Production environment.  This is probably what's causing the issue.

I'm guessing it has to do with the Production boxes local or global security policies.  Or a permissions thing. 

QA in this case was meanth for Query Analyser

So when I run the sproc from query analyser, everythig works fine,

If I schedule a sqlagent job the start when sqlagent starts, everything works fine,

When I set the same sproc for startup proc, then the proc to get the registrykey fails

For the moment the sqlagent job is scheduled to start whenever sqlagent starts (is autostarted on this box)  and this workaround has been accepted.

     Jul 13  

Sometimes this is me

Ah. Okay.  Sorry about the misinterpretation. 

At least you got it working.