views:

94

answers:

5

I have a query like this:

SELECT TOP 1 ID, DATA, OTHERINF FROM MYTABLE WHERE DATE = @DATE

and after reading the row data and using it I want to update that retrieved row and change one of it's columns (in another transaction).

But as you see here i searched for that row twice. Is there anyway that I keep remember the row and do the update without searching again.

Thank you.

A: 
--Note, need to setup proper data types
DECLARE @Id INT
DECLARE @Data VARCHAR(MAX)
DECLARE @OtherInf VARCHAR(max)

SELECT TOP 1 @id = Id, @Data = Data, @OtherInf = OtherInf
FROM MyTable
WHERE Date = @Date

--Now you can do what you need, using the info above.

This should do it

Mitchel Sellers
But I wanted a way for not searching twice. Your solution just provided information not a way for solving the problem.
Shayan
You note that you are wanting to use the information in ANOTHER transaction, therefore, I would assume that you have intermediate processing.
Mitchel Sellers
+4  A: 

In the first query you retrieved the id. In the second query use that to find the row to update instead of using the date:

UPDATE MYTABLE
SET DATA = 'FooBar'
WHERE ID = 200
Mark Byers
Note that this presumes that ID is PK or at least indexed.
Michael Bray
+1 No need to search as long as you hang on to an indexed column.
Jon
But this way I should have an index on id. Any better way?
Shayan
Your id isn't indexed? Don't you have any primary key for your table? Having a primary key *is* the better way.
Mark Byers
Does primary key mean having an index on that column?
Shayan
No, those two terms aren't interchangeable. Primary keys are always indexed, but you can also have indexed columns that are not part of the primary key.
Mark Byers
I didn't know that primary keys are always indexed. Do you have any link that show this fact?
Shayan
@Shayan: Did you try Google? "PRIMARY KEY is a constraint that enforces entity integrity for a given column or columns through a unique index. Only one PRIMARY KEY constraint can be created per table." From MSDN: http://msdn.microsoft.com/en-us/library/aa258255%28SQL.80%29.aspx
Mark Byers
A: 

You can combine the UPDATE with the SELECT into one statement, but not across two transactions. Therefore, if you need to update the value in another transaction than you select it (the reason for this is unclear to me), you need two statements.

Lucero
A: 

I presume that the DATE column isn't indexed (if not, why not?) Your best bet, then, is to make sure you retrieve the primary key (isn't that ID?) and then use that as your condition in the update.

Michael Bray
I have an index on DATE.
Shayan
A: 

I know its out of vogue but you can also do positioned updates on cursors e.g.

use Northwind
GO



DECLARE EMP_CURSOR CURSOR 
FOR SELECT TOP 1 EmployeeID, LastName FROM EMPLOYEES WHERE  HireDate = '1994-11-15'
FOR UPDATE OF LastName

OPEN EMP_CURSOR

FETCH NEXT FROM EMP_CURSOR 

UPDATE EMPLOYEES
SET LastName = LastName + CAST(DatePart(ms,GetDate()) as char(3))
WHERE CURRENT OF EMP_CURSOR


CLOSE EMP_CURSOR

DEALLOCATE  EMP_CURSOR
Conrad Frix
Do cursors remain between different transactions?
Shayan
Cursors remain open until either they are closed or the connection is closed. So it depends a lot on you. Note that 2005 added LOCAL and GLOBAL keywords to cursors
Conrad Frix