Re: asynchronous select statements
From: Mike Epprecht \(SQL MVP\) (mike_at_epprecht.net)
Date: 02/15/05
- Next message: Mark: "StoredProc or Dynamic SQL?"
- Previous message: Jeremy Chapman: "asynchronous select statements"
- In reply to: Jeremy Chapman: "asynchronous select statements"
- Next in thread: oj: "Re: asynchronous select statements"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 16 Feb 2005 00:07:26 +0100
Have the app call a single SP.
This SP updates the record, and then returns it to the client application.
This is in one transaction, so the other application can not get to the same
record.
Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Jeremy Chapman" <NoSpam@Please.com> wrote in message
news:#GXM3G7EFHA.1084@tk2msftngp13.phx.gbl...
> We have an application deployed on two seperate machines both reading from
> the same database. The applications poll the database every few seconds
and
> find the first record in a table that has a bit field set to 0x0. The
> application then updates the field to a value of 0x1 and then do some
> processing based on the contents of the record. The problem we have is
that
> it is currently possible for each application to get the same record
because
> application 2 might select the record just before application 2 updates
the
> bit flag. we currently use two sql calls (in stored procs) such as:
>
> select top 1 * from table1 where processed = 0x0
>
> update table1 set processed = 0x1 where recid = @ID
>
>
> How can we avoid both apps getting the same record
>
>
- Next message: Mark: "StoredProc or Dynamic SQL?"
- Previous message: Jeremy Chapman: "asynchronous select statements"
- In reply to: Jeremy Chapman: "asynchronous select statements"
- Next in thread: oj: "Re: asynchronous select statements"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
