• MplsSQLDevGuy (unregistered)

    The value returned from a stored procedure call is always an integer, so naming it a message (@msg) is misleading. If there's no explicit return value, the default is zero. So, acting on a zero value means procedures are explicitly returning some other integer to signal something. All around a bad idea. That's what explicitly named OUTPUT parameters (which can be of any type) are for.

  • (nodebb)

    They declare '@msg' as VARCHAR(30), but then say, when converting '@result' to a string, it's a VARCHAR(10)? Sounds like copy-paste ("vibe") programming.

  • (nodebb)

    By convention, the return value from a stored procedure is a status indicator, with zero meaning "Success" and non-zero indicating some kind of error. As @MplsSQLDevGuy says, if you want to return values to a variable, you use output parameters.

    And, yes, this should have been

    exec @status = do_something @param1 = ... if @status != 0 ...

  • L (unregistered)

    also let's hope that app has at most a single user because there is a race condition between the query and the get_last_message call

  • (nodebb) in reply to L

    Plot twist: maybe the race condition is what was being debugged in the first place?

Leave a comment on “Message Oriented Database”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article