Home/ Questions/Q 914489
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T17:43:35+00:00

I was looking for any suggestion or a good approach to handle messages between

  • 0

I was looking for any suggestion or a good approach to handle messages between the data & application tier, what i mean with this is when using store procedures or even using direct SQL statements in the application, there should be a way the data tier notifies upper layers about statement/operation results in at least an organized way.

What i commonly use is two variables in every store procedure:

@code INT,
@message VARCHAR(1024)

I put the DML statements inside a TRY CATCH block and at the end of the try block, set both variables to certain status meaning everything went ok, as you might be thinking i do the opposite on the catch block, set both variables to some failure code if needed perform some error handling.

After the TRY CATCH block i return the result using a record:

SELECT @code AS code, @message AS message

These two variables are used in upper tiers for validation purposes as sending messages to the user, also for committing o rolling back transactions.

Perhaps i’m missing important features like RAISERROR or not cosidering better and more optimal and secure approaches.

I would appreciate your advices and good practices, not asking for cooks recipes there’s no need, just the idea but if you decide to include examples they’d be more than welcome.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The generally accepted approach for dealing with this is to have your sproc set a return values
    and use raise error as has been previously suggested.

    The key thing that I suspect you are missing is how to get this data back on the client side.

    If you are in a .net environment, you can check for the return value as part of the ado.net code. The raise error messages can be captured by catching the SqlException object and iterating through the errors collection.

    Alternatively, you could create and event handler and attach to the connection InfoMessage event. This would allow you to get the messages as they are generated from sql server instead of at the completion of the batch or stored procedure.

    another option which I wouldn’t recommend, would be to track all of the things you care about into a XML message and return that from the stored proc this gives you a little more structure then your free text field approach.

    • 0