UPDATE SELECT

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2008 » T-SQL (SS2K8) » UPDATE SELECT

21 posts, Page 1 of 3

1 2 3 »»»

UPDATE SELECT

Rate Topic

Display Mode

Topic Options

Author

Message

Sean Grebey-262535

Posted Thursday, January 27, 2011 8:35 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 08, 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

John Mitchell-245523

Posted Thursday, January 27, 2011 8:47 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Tuesday, June 04, 2013 7:03 AM
Points: 4,443, Visits: 7,249

UPDATE t2
SET column1 = t1.column1, column2 = t1.column2,...
FROM table1 t1 JOIN table2 t2
ON t1.ID = t2.ID

John

Post #1054638

Sean Grebey-262535

Posted Thursday, January 27, 2011 8:50 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, February 08, 2012 7:47 AM
Points: 124, Visits: 132

Thank you.

Post #1054640

CELKO

Posted Thursday, January 27, 2011 10:18 AM

SSCommitted

Group: General Forum Members
Last Login: Tuesday, January 15, 2013 11:11 AM
Points: 1,945, Visits: 2,782

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

John Mitchell-245523

Posted Friday, January 28, 2011 2:04 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Tuesday, June 04, 2013 7:03 AM
Points: 4,443, Visits: 7,249

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

CELKO

Posted Friday, January 28, 2011 9:00 AM

SSCommitted

Group: General Forum Members
Last Login: Tuesday, January 15, 2013 11:11 AM
Points: 1,945, Visits: 2,782

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

John Mitchell-245523

Posted Wednesday, February 02, 2011 4:06 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Tuesday, June 04, 2013 7:03 AM
Points: 4,443, Visits: 7,249

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

Sean Lange

Posted Wednesday, February 08, 2012 7:43 AM

SSCrazy Eights

Group: General Forum Members
Last Login: Today @ 3:12 PM
Points: 8,957, Visits: 8,523

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

Post #1248980

John Mitchell-245523

Posted Wednesday, February 08, 2012 7:46 AM

SSCarpal Tunnel

Group: General Forum Members
Last Login: Tuesday, June 04, 2013 7:03 AM
Points: 4,443, Visits: 7,249

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

Sean Lange

Posted Wednesday, February 08, 2012 7:52 AM

SSCrazy Eights

Group: General Forum Members
Last Login: Today @ 3:12 PM
Points: 8,957, Visits: 8,523

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. Tongue

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

Post #1248991

« Prev Topic | Next Topic »

21 posts, Page 1 of 3

1 2 3 »»»

Permissions