December 9, 2005 at 6:33 am
I have a procedure and in that I am reading a trace file using ::fn_trace_gettable, becasue of the corrupted trace file the procedure fails and the entire procedure skipped
create procedure Trace_Test_sub(@FileName varchar(1000))
As
select count(*) from ::fn_trace_gettable(@FileName, default)
if @@error<>0
print 'there is an error'
I am not able to catch this error using @@error , once the error occurs the entire procedure get skipped with an error message.
Is there any way to handle/catch these kind of errors ?? please help.
subban
December 9, 2005 at 1:38 pm
I have set up tracing on about 80 Servers that runs on a 24x7 basis with the trace being stopped and then restarted once a day and have run into this error
Server encountered an error
'D:\Audit\Pending\USASCHIRPTDB1_Audit_20051207T050000737.trc'. [SQLSTATE 42000] (Error 568).
As error 568 has a severity level of 16, SQL Server terminates the batch and return control to the client program. You cannot cannot catch the error of serverity level 16 from within SQL only from a client program.
SQL = Scarcely Qualifies as a Language
December 9, 2005 at 2:47 pm
Wrap the test in some client code capable of catching the error. I know this is a kludge, but it's really the only way to do so. Technically you could do so using SQL Server Agent.
K. Brian Kelley
@kbriankelley
December 11, 2005 at 10:22 pm
thanks a lot - Bkelley.
canu give some tips on how to do this thing (wrap this in to client code)
subban
December 15, 2005 at 7:29 am
When we do heartbeat checks on our SQL Servers, we basically monitor to see a connection can be made. We do this through an ADO connection. If you perform a connection using ADO, you have access to the ADO error object. So any bit of code, VBScript, VB, a .NET app, etc. will work for you.
K. Brian Kelley
@kbriankelley
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply