UPDATE SELECT
-
Does somebody have an update select script they can post for me. I knwo I've done them before but I'm drawing a blank. Basically I need to update the fields from one table with the current values from another table based on a matching ID. e.g.
Where T1.ID = T2.ID, Set T1.Addr1 = T2.Addr1, T1.City = T2.City, etc...
Thanks.
-
UPDATE t2SET column1 = t1.column1, column2 = t1.column2,...
FROM table1 t1 JOIN table2 t2
ON t1.ID = t2.ID
John
-
Thank you.
-
Joe
I really don't care that it doesn't port. This is a SQL Server forum and if the original poster had wanted something that works on Oracle as well, he would have (or should have) said. However, I'm interested in these cardinality errors. Do you have a link that explains this? A quick search revealed nothing helpful, and the documentation in Books Online for MERGE doesn't mention it.
Thanks
John
-
Thanks for taking the time to explain that, Joe. I understand what the problem is now - where you have a many-to-one relationship between the two joined tables, the UPDATE FROM syntax effectively updates the parent table with all of the values from the child table, leaving the value from the physically last row as the one that persists.
I'm still not 100% convinced by your portability argument. I absolutely agree that just as a writer should know standard English, a developer should be aware of the standards in any particular programming language. However, programmers (and writers) should also know when it is appropriate to deviate from those standards. Each DBMS has its own features that distinguish it from its rivals and which, in some cases, provide extra features or performance. I see no reason why such features should not be used where they improve on ISO SQL.
I also agree that maintenance may be more difficult on non-standard code. When dialect provides no benefits above what can be achieved using standard code, you are right: the ISO-compatible construction should be used. This is not a reason, though, to fail to take advantage of the features of any particular DBMS. Needless dialect should indeed be avoided, but because it's needless, not because it's dialect.
John
-
I too get the point about cardinality issues but the example really is more of a logic flaw than anything else. The example you provided has some serious issues that should never show up in a normal system. If you were going to update the Orders table to set some_col it is painfully obvious that it should be the sum of OrderDetails and not the first one it finds. So even with ANSI syntax the logic error still exists.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/ -
Yes, but the point is that with UPDATE...FROM, you'll never know about it. If you use the ANSI syntax, you'll get an error message.
John
-
John Mitchell-245523 (2/8/2012)
Yes, but the point is that with UPDATE...FROM, you'll never know about it.John
At least until the users start screaming that their data is wrong. 😛
If you use the ANSI syntax, you'll get an error message.
I didn't think about the subquery returning more than 1 row error because the logic flaw was so glaringly obvious but of course the example is a simple one.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/ -
Very interesting post...
I must be missing something fundamental here as I can't see what the problem is with using UPDATE... FROM. In CELKO's example there is nothing to specify what value is used to update the parent - is this what the problem is? If so surely its down to the developer / administrator to realise that there is no guarantee what value will be used in the update. Seemed quite obvious to me...
[font="Times New Roman"]There's no kill switch on awesome![/font] -
The non-deterministic behaviour of UPDATE..FROM is well known and fully documented in BOL. There are other non-deterministic functions in SQL Server such as the ANSI compliant ROW_NUMBER - would you ban that as well?
____________________________________________________
Deja View - The strange feeling that somewhere, sometime you've optimised this query before
How to get the best help on a forum
http://www.sqlservercentral.com/articles/Best+Practices/61537
-
Mark-101232 (2/8/2012)
The non-deterministic behaviour of UPDATE..FROM is well known and fully documented in BOL. There are other non-deterministic functions in SQL Server such as the ANSI compliant ROW_NUMBER - would you ban that as well?Who is this question directed at Mark?
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi -
SQL Kiwi (2/8/2012)
Mark-101232 (2/8/2012)
The non-deterministic behaviour of UPDATE..FROM is well known and fully documented in BOL. There are other non-deterministic functions in SQL Server such as the ANSI compliant ROW_NUMBER - would you ban that as well?Who is this question directed at Mark?
Ha! It's not directed at any one person, just a general point.
____________________________________________________
Deja View - The strange feeling that somewhere, sometime you've optimised this query before
How to get the best help on a forum
http://www.sqlservercentral.com/articles/Best+Practices/61537 -
surely its down to the developer / administrator to realise that there is no guarantee what value will be used in the update.
Precisely. Would you use that syntax if there were no guarantee what would happen when you did so?
The non-deterministic behaviour of UPDATE..FROM is well known and fully documented in BOL.
Fully documented - maybe, although a quick search just now didn't reveal anything. Well known - I'd dispute that. I think there are a lot of people who use it (myself included, up to a year ago) without understanding the implications.
There are other non-deterministic functions in SQL Server such as the ANSI compliant ROW_NUMBER - would you ban that as well?
I don't see how that's relevant to this discussion. We're talking about non-deterministic updates, not non-deterministic functions. In any case, I'm not saying anything should be banned. I'm just expressing the opinion that this particular syntax should not be used unless there are compelling reasons to do so (and I don't deny that such compelling reasons do exist).
John
-
John Mitchell-245523 (2/8/2012)
surely its down to the developer / administrator to realise that there is no guarantee what value will be used in the update.
Precisely. Would you use that syntax if there were no guarantee what would happen when you did so?
The non-deterministic behaviour of UPDATE..FROM is well known and fully documented in BOL.
Fully documented - maybe, although a quick search just now didn't reveal anything. Well known - I'd dispute that. I think there are a lot of people who use it (myself included, up to a year ago) without understanding the implications.
There are other non-deterministic functions in SQL Server such as the ANSI compliant ROW_NUMBER - would you ban that as well?
I don't see how that's relevant to this discussion. We're talking about non-deterministic updates, not non-deterministic functions. In any case, I'm not saying anything should be banned. I'm just expressing the opinion that this particular syntax should not be used unless there are compelling reasons to do so (and I don't deny that such compelling reasons do exist).
John
Documented here
http://msdn.microsoft.com/en-US/library/ms177523(v=sql.90).aspx
In the section "Using UPDATE with the FROM Clause"
____________________________________________________
Deja View - The strange feeling that somewhere, sometime you've optimised this query before
How to get the best help on a forum
http://www.sqlservercentral.com/articles/Best+Practices/61537
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply