Re: row vs row.column level locking

sybrandb_at_hccnet.verwijderdit.nl wrote:
> On Fri, 16 Dec 2005 18:43:52 GMT, netcomradeNSPAM_at_bookexchange.net
> (NetComrade) wrote:
>
> >Your name will most likely be stored in a separate table if the table
> >is normalized :) The PK on your account would be the account#. Unless
> >there is a additional business logic, I see no issues (on the db side)
> >of updating your name while you're making a deposit.
>
> Obviously this is an example that doesn't support your 'case' at all.
> How about a different example:
> A call has a start date, and based upon a SLA, a call to fix date.
> What about one process updating the call to fix (the algorithm is
> quite complicated, so it can't be set upon insert)

How does this too-complicated-to-happen-on-insert process get fired?

> and another process
> updating the start date?

Why should updates to the start data ever happen in the first place?

> Should that be allowed?

Depends. How does the process get fired?

> If that, according to you, shouldn't be allowed, please admit the
> concept of column level locking is quite often completely absurd.

Row level locking is also quite often completely absurd. Features should be evaluated based on how often they are appropriate, not on whether they are ever not appropriate.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB