[VXCMD] Record Locks

[Ruslan Zasukhin]

On 8/24/04 12:09 AM, "Ken Ray" <kray at sonsothunder.com> wrote:

>> Again, right now it works 100% correctly by db theory.
>> You want READ records, you must set READ LOCK on them at first.
>> 
>> Again the same example:
>> 
>> user1 do:
>>         
>>     SELECT * FROM T WHERE fld1 = 200
>> 
>> He find 100 records which have fld1 value equal to 200.
>> If now user2 in the same will change 95th record fld1 to 350,
>> Then user1 will read 350 value. You see?
>> 
>> So user1 get problem: non consistent data.
> 
> I don't understand why it wouldn't be consistent data... user1 is getting
> the current values of the records in the table at the time the query hits
> those records, so *yes*, he will get the changed 95th record, but I don't
> understand why that is a problem if he's just *getting* the data, and not
> *setting* it? 

Because:

* the first and main rule of TRANSACTIONS and multi-user work say:

    User must work in multi-user environment in such way,
    like other users not exists.
    User must not see the work of other users.

    You can read this in any book which describe you SQL,
    transactions, servers.


* Db theory says that user1 see inconsistent data because he HAVE ASK for
records WHERE fld1 = 200. IF user1 see in this cursor record with fld1 =
350, then what he should think?! He should think:
    what a stupid DBMS! I have ask it fld1 = 200.
    but what it give me????

And he have all rights to think so.
Just image that he really works along on server.
Then he will always get correct data. fld1 = 200.
So why he should still get the same data if other user come!
This is named "consistent".

Yes, usually DBMS have several modes of work.
The case which you ask for, is named DIRTY READ.

And user1 self EXPLICITLY MUST TO say: I want DIRTY READ.
Then only DBMS say:
    okay, I give up, I will not protect you.    :-)


> And if he *really* wanted to lock it down, he could do
> SQLSelect with a read-only cursor and do it that way.

Actually it must be visa versa.

On default works SAFE MODE.
If you want danger mode, DIRTY READ, then YOU MUST ask for this.

 
> Again, my comments are related to SQLSelectRecords, which AFAIK most other
> DBMSes *don't* do - they make you create a cursor, fill the cursor, get the
> data from the cursor, and dispose the cursor. SQLSelectRecords is a
> wonderful thing, but I don't think that preventing people from being able to
> open records that are being read from a list is of benefit to the DB
> developer.
> 
> Perhaps this argument is moot if the problem really is a bug in
> SQLSelectRecords where its "read only" is bumping against a "no lock" and
> causing a record lock when it shouldn't. If this is true, and it is fixed so
> that "read only" vs. "no lock" doesn't cause any problems, then I'm OK with
> leaving SQLSelectRecords as "read only".

-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------