Getting sp_tracegenerateevent to work in a stored procedure

Question

I\'m having a hard-time debugging a stored procedure called from BizTalk.

In a prior thread, someone suggested using sp_trace_generateevent. [Use SQL Debugger when sto

Answer 1

It turns out that BizTalk calls the Stored Proc twice, once with FmtOnly=On and once again with FmtOnly=Off. I was getting the invalid cast exception after the first call, so the Stored Proc was essentially not really executing. I was mislead by the profiler because of the FmtOnly=On, thinking that it was actually executing the statements I saw there. Thus the sp_TraceGenerateEvent doesn't actually run on the first pass with FmtOnly=On, but later when I got past the other errors, it works fine in the second pass with FmtOnly=Off.

Reference: Similar questoin I posted about why the SQL Profiler was looking different between an SSMS run and a BizTalk run of same stored proc: Can SQL Begin Try/Catch be lying to me (in the profiler)?

Answer 2

Well, if you try this:

SET XACT_ABORT ON;
BEGIN TRY   
    SELECT 1 / 0;
END TRY
BEGIN CATCH
    DECLARE @message nvarchar(128);
    SET @message = LTRIM(STR(ERROR_MESSAGE()));
    exec sp_trace_generateevent @event_class=82, @userinfo = @message
END CATCH

You'll get immediate feedback on what's wrong:

Msg 8114, Level 16, State 5, Line 8 Error converting data type nvarchar to float.

And that's because that STR() call you've got is not the right thing to use -- STR formats floating-point values, and only those. (For flexible conversion, use FORMAT and/or CONCAT, the latter of which always implicitly converts things to strings without complaining.)

Aside from that, the first parameter of the stored procedure is @eventid, not @event_class (this is normally an error, but extended stored procedures are more flexible that way -- you could call the parameter @banana and it will still work). Still, for clarity's sake we should use the documented name. So:

SET XACT_ABORT ON;
BEGIN TRY   
    SELECT 1 / 0;
END TRY
BEGIN CATCH
    DECLARE @message nvarchar(128) = ERROR_MESSAGE();
    EXEC sp_trace_generateevent @eventid=82, @userinfo = @message;
END CATCH

And in my profiler, this produces a UserConfigurable:0 event with

Divide by zero error encountered.

Note that if there is no TRY / CATCH, you should still be able to get errors even without generating your own trace event, through the Exception event.