Page 1 of 2 12 LastLast
Results 1 to 15 of 23
  1. #1
    Join Date
    Jan 2008
    Posts
    186

    Unanswered: UPDATE multiple tables

    Hi,

    Can I update multiple tables within the same UDPATE statement?

    e.g.
    Code:
    UPDATE cat, orders, tags
    SET cat.display = 'starting', orders.tag_id = tags.tag_id
    WHERE cat.id = orders.id AND orders.cost = @price AND tags.state = 'sold'
    I keep getting an error
    Code:
    Incorrect syntax near ','.

  2. #2
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    no. u can not.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

  3. #3
    Join Date
    Jan 2008
    Posts
    186
    that sucks

    is the main work-around for this just to use separate update statements?

  4. #4
    Join Date
    Sep 2005
    Posts
    161
    Yes, multiple update statements. You can encapsulate the statements inside one stored procedure if you want.

  5. #5
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Quote Originally Posted by cascred
    You can encapsulate the statements inside one stored procedure if you want.
    It should be replaced with MUST!!!
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  6. #6
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Don't forget to wrap the statements in a transaction; gotta be sure they all work, or none of them at all
    George
    Home | Blog

  7. #7
    Join Date
    Jan 2008
    Posts
    186
    Quote Originally Posted by georgev
    Don't forget to wrap the statements in a transaction; gotta be sure they all work, or none of them at all
    That's what I was afraid of... How can I do this?

    BTW: Shouldn't this be done for ALL stored procedures? E.g. What are the disadvantages of making every stroed proc a transaction?

  8. #8
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    You base your transactions on your business requirements. It would usually mean you want to commit or rollback ALL the work done in a sproc, but not necessarily. I don't like rules like "start and end ALL sprocs with BEGIN TRAN and COMMIT TRAN" - it is too absolute. This will be the case most of the time but not always.

  9. #9
    Join Date
    Jan 2008
    Posts
    186
    Quote Originally Posted by pootle flump
    You base your transactions on your business requirements. It would usually mean you want to commit or rollback ALL the work done in a sproc, but not necessarily. I don't like rules like "start and end ALL sprocs with BEGIN TRAN and COMMIT TRAN" - it is too absolute. This will be the case most of the time but not always.
    do you know if there's any performance drop with doing this?

  10. #10
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Depends. Again there is no absolute. Besides, this again is something determined by your business requirements. It is an integrity consideration. If integrity is required then it is required.

    I certainly wouldn't expect anything measurable unless you are talking about massive data movement.

  11. #11
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Every TSQL statement (except for create/drop database, and select) should be wrapped in the following construct:

    begin tran
    <TSQL statement>
    if @@error != 0 begin
    <error_handler>
    rollback tran
    return (1)
    end
    commit tran

    You may choose to use try/catch construct only if you feel more comfortable with it, but transactional control applies here as well.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  12. #12
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by rdjabarov
    Every TSQL statement (except for create/drop database, and select) should be wrapped in the following construct
    Got to disagree Robert - unless you mean every discrete transaction (which may of course be composed of a series of SQL statements).

  13. #13
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    I mean every statement that either changes data or structure of the database.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  14. #14
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    But what about the classic example of moving money from one bank account to another. You are wrapping those TWO statements into a single transaction right?

  15. #15
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    what's the point in wrapping a single update in an expcict transaction instead of just using the implicit transaction?

    Is it the return code that you are particular about?

    Again please excuse my utter ignorance and immaturity and thank you for your time and patience.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •