Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

UPDATE SELECT Expand / Collapse
Author
Message
Posted Thursday, January 27, 2011 8:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 8, 2012 7:47 AM
Points: 124, Visits: 132
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.
Post #1054628
Posted Thursday, January 27, 2011 8:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:55 AM
Points: 5,421, Visits: 10,077
UPDATE t2
SET column1 = t1.column1, column2 = t1.column2,...
FROM table1 t1 JOIN table2 t2
ON t1.ID = t2.ID

John
Post #1054638
Posted Thursday, January 27, 2011 8:50 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 8, 2012 7:47 AM
Points: 124, Visits: 132
Thank you.
Post #1054640
Posted Thursday, January 27, 2011 10:18 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 11:21 AM
Points: 1,945, Visits: 3,062
Look up the MERGE statement. It is ANSI/ISO Standard and will catch cardinality errors. Never use the proprietary, Sybase code museum UPDATE..FROM.. syntax. It allows cardinality errors without warning and does not port.


Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1054725
Posted Friday, January 28, 2011 2:04 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:55 AM
Points: 5,421, Visits: 10,077
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
Post #1055153
Posted Friday, January 28, 2011 9:00 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 11:21 AM
Points: 1,945, Visits: 3,062

CREATE TABLE Orders
(order_nbr INTEGER NOT NULL PRIMARY KEY,
some_col DECIMAL (9,2) NOT NULL);

INSERT INTO Orders VALUES (1, 0);
INSERT INTO Orders VALUES (2, 0);
INSERT INTO Orders VALUES (3, 0);

CREATE TABLE OrderDetails
(order_nbr INTEGER NOT NULL,
sku INTEGER NOT NULL,
item_price DECIMAL (9,2) NOT NULL,
PRIMARY KEY(order_nbr, sku),
-- FOREIGN KEY(sku) REFERENCES Products(sku)
FOREIGN KEY(order_nbr) REFERENCES Orders(order_nbr));

INSERT INTO OrderDetails VALUES (1, 1, 500.00);
INSERT INTO OrderDetails VALUES (1, 2, 205.00);
INSERT INTO OrderDetails VALUES (2, 1, 490.95);
INSERT INTO OrderDetails VALUES (3, 1, 480.00);

SELECT * FROM Orders;

UPDATE Orders
SET Orders.some_col = OrderDetails.item_price
FROM Orders
INNER JOIN
OrderDetails
ON Orders.order_nbr = OrderDetails.order_nbr;

results -- see item #1; last physical value
1 205.00 - where is the $500.00?
2 490.95
3 480.00
*/


--repeat with new physical ordering
DELETE FROM OrderDetails;
DELETE FROM Orders;
DROP INDEX OrderDetails.foobar;

-- index will change the execution plan
CREATE INDEX foobar ON OrderDetails (order_nbr, item_price);

INSERT INTO Orders VALUES (1, 0);
INSERT INTO Orders VALUES (2, 0);
INSERT INTO Orders VALUES (3, 0);

INSERT INTO OrderDetails VALUES (1, 2, 205.00);
INSERT INTO OrderDetails VALUES (1, 1, 500.00);
INSERT INTO OrderDetails VALUES (2, 1, 490.95);
INSERT INTO OrderDetails VALUES (3, 1, 480.00);

UPDATE Orders
SET Orders.some_col = OrderDetails.item_price
FROM Orders
INNER JOIN
OrderDetails
ON Orders.order_nbr = OrderDetails.order_nbr;

SELECT * FROM Orders;

/*
Results
1 500.00
2 490.95
3 480.00
*/

What is the first property that you must have in an INDEX? It cannot change the results of a statement, only the performance. See the problem?

This would not have happened with the ANSI syntax. That's the point that I am trying to make. The ANSI equivalent of the incorrect query above is

UPDATE Orders
SET some_col
= (SELECT item_price
FROM OrderDetails
WHERE OrderDetails.order_nbr = Orders.order_nbr)
WHERE EXISTS
(SELECT *
FROM OrderDetails
WHERE OrderDetails.order_nbr = Orders.order_nbr);

In the Sybase days, it was worse. You could get a running total instead of a cardinality exception or a random choice made by the hardware.

The portability issue:

1) Would you respect a technical writer who did not know Standard English grammar and spelling? Or would he be less than processional? Same with programmers who write needless dialect.

2) If you are the poor bastard who has to maintain an application (where over 80% of the lifetime cost is accrued), would you like to see ANSI/ISO Standard code or a a module dependent on a local dialect from a past release with deprecated features?





Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1055381
Posted Wednesday, February 2, 2011 4:06 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:55 AM
Points: 5,421, Visits: 10,077
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
Post #1057325
Posted Wednesday, February 8, 2012 7:43 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 10:06 AM
Points: 13,082, Visits: 12,537
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 Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1248980
Posted Wednesday, February 8, 2012 7:46 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:55 AM
Points: 5,421, Visits: 10,077
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
Post #1248983
Posted Wednesday, February 8, 2012 7:52 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 10:06 AM
Points: 13,082, Visits: 12,537
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 Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1248991
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse