[VXCMD] Record Locks

Ruslan Zasukhin sunshine at public.kherson.ua
Mon Aug 23 23:46:41 CDT 2004


On 8/23/04 11:07 PM, "Ken Ray" <kray at sonsothunder.com> wrote:

>>> (BTW: The main reason Bobby and I experienced this is that we have someone
>>> from New York accessing a database in LA, and the latency caused by the
>>> long-distance access caused our SQLSelectRecords call to tie up all the
>>> records during that period.)
>> 
>> Aha! this is an answer.
>> 
>> So SqlSelectRecords() have lock records with READ LOCK,
>> And other users could not access them for WRITE LOCK, right Ken?
> 
> Sorry, Ruslan, but no. ALL of our cursors that are done with SQLSelect() are
> NoLock cursors. So we only have NoLock SQLSelect() cursors and
> SQLSelectRecords() cursors (which are as you said ReadOnly and so run into
> each other and cause the 363).

Hmm, then I do not see where from come 363 error.

Somebody must set or try to set WRITE lock.

If all set READ LOCK and NO LOCK, then there is no conflict.

 
>> What you think now?
>> 
>> I think SqlSelectRecords() works now in the correct way.
> 
> I don't... personally since SQLSelectRecords() only retrieves data and does
> not change it, I think you should use kNoLocks rather than kReadOnly.... I
> don't see the advantage of using kReadOnly instead of kNoLocks with
> SQLSelectRecords.

Ken, then this function will work not correctly if you will use WRITE LOCKS.

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.

To prevent this, user1 MUST set READ LOCK, so nobody cannot change records
until he finish read it. Yes user2 must wait.


>> At last of end if you want OTHER way, you simply should use
>> Cursor_GetRecords() and own cursor with parameters as you want.
>> Right ?
> 
> Well, I would prefer to not have to replace my one line SQLSelectRecords
> calls with three lines of SQLSelect(), Cursor_GetRecords(), Cursor_Remove().

Then we need new parameters, and you still must update code to use them.


But again, I do not see where from your get 363 error!


-- 
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
-------------------------------------------------------------



More information about the Valentina mailing list