Update Statement - Differences between SQL Versions?

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2008 » SQL Server 2008 - General » Update Statement - Differences between SQL...

Update Statement - Differences between SQL Versions?

Rate Topic

Display Mode

Topic Options

Author

Message

dougjjj

Posted Wednesday, September 19, 2012 7:57 PM

SSC-Addicted

Group: General Forum Members
Last Login: 2 days ago @ 11:52 PM
Points: 446, Visits: 351

Hi,

I've been having a chat with Google and haven't been able to find an answer to it so here goes ...

I have 2 servers, one SQL 2008 R2 & the other SQL 2000, both using the same data, same SQL Statements & same Collation and they are returning different results.

The SELECT statement of the UPDATE returns multiple rows for each row that is updated. SQL 2008 R2
uses the values from the First row returned and SQL 2000 is using the values from the Last row returned for each update.

Example below ...
- If I run the code below on a SQL 2008R2 machine the result is 1.
- If I run the code below on a SQL 2005 machine the result is 1.
- If I run the code below on a SQL 2000 machine the result is 3.

CREATE TABLE #Test
(
	Row INT IDENTITY (1, 1),
	Result INT
)

CREATE TABLE #UpdateResult
(
	Result INT
)

INSERT	#UpdateResult
SELECT	0

INSERT #Test
SELECT 1

INSERT #Test
SELECT 2

INSERT #Test
SELECT 3

UPDATE	#UpdateResult
SET	Result = #Test.Result 
FROM	#Test

SELECT	* 
FROM	#UpdateResult

DROP TABLE #UpdateResult
DROP TABLE #Test

Questions ...
- Huh?
- Is this a setting that is specified anywhere? If so can it be changed?

Post #1361704

dwain.c

Posted Thursday, September 20, 2012 12:45 AM

SSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:42 AM
Points: 2,338, Visits: 3,158

I've seen this sort of "inconsistent" result on UPDATEs where you're applying multiple rows to a single row and I don't believe it is controlled by a setting.

You need to control it by specifying which row of #Test updates the #UpdatedResults table, like by using a WHERE clause.

No loops! No CURSORs! No RBAR! Hoo-uh!

INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Are you too recursively challenged?
Splitting strings based on patterns can be fast!

Post #1361756

dougjjj

Posted Thursday, September 20, 2012 5:15 PM

SSC-Addicted

Group: General Forum Members
Last Login: 2 days ago @ 11:52 PM
Points: 446, Visits: 351

I had a feeling that would be the case. We're currently migrating an old Datawarehouse from SQL 2000 to SQL 2008 R2 and obviously we want the data to match across the systems.

Fixing the problem is easy enough but this means we are left with inconsistencies between the two systems which isn't ideal.

Post #1362380

« Prev Topic | Next Topic »

Permissions