Re: UPDATE and ALTER in transactions do not mix
- From: "Baz" <bazz@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 5 Aug 2005 09:58:32 +0100
"Jamie Collins" <jamiecollins@xxxxxxxxxx> wrote in message
news:1123226123.607617.250400@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Jonathan Scott via AccessMonster.com wrote:
> > It seems reasonable to you that an UPDATE should keep a row locked even
after
> > it has been completed? In other words, it is reasonable that a row can
only
> > be touched once inside of a single transaction?
>
> What locking strategy are you (or think you are) using?
>
It isn't a question of locking strategies, it's a question of how
transaction protection works. When you do an UPDATE inside a transaction,
the record HAS to stay locked until the transaction is committed.
> Sounds reasonable to me, especially considering you can legitimately do
> things the other way around i.e. ALTER before UPDATE.
Of course it works the other way round: the ALTER doesn't take out any
locks. But, if SOMEONE ELSE had the table open at the same time, I'm pretty
sure that the ALTER would fail.
> What kind of
> application are you writing that mixes DML and DDL in the same
> transaction?
Good question!
.
- References:
- UPDATE and ALTER in transactions do not mix
- From: Jonathan S via AccessMonster.com
- Re: UPDATE and ALTER in transactions do not mix
- From: Baz
- Re: UPDATE and ALTER in transactions do not mix
- From: Jonathan Scott via AccessMonster.com
- Re: UPDATE and ALTER in transactions do not mix
- From: Jamie Collins
- UPDATE and ALTER in transactions do not mix
- Prev by Date: Re: UPDATE and ALTER in transactions do not mix
- Next by Date: Re: Do not want data to auto sort
- Previous by thread: Re: UPDATE and ALTER in transactions do not mix
- Next by thread: Re: UPDATE and ALTER in transactions do not mix
- Index(es):
Relevant Pages
|