VCursor lock question

[Fran=?ISO-8859-1?B?5w==?=ois Van Lerberghe]

Vcursor is not created automatically in Read and Write mode. In order to
update a record, you must
- create the VCursor with the parameter EVLokType.kReadWrite (or kNoLock)
or
- issue a SQL query directly ("UPDATE myTable SET...WHERE...")

I'm using the first way and this cause that I cannot get a second cursor in
Read and Write mode because the records are already locked. If I set the
first Vcursor to nil, I can get the second but there is a risk that, just
before the creation of the second Vcursor, another user get some records in
write mode and then, I cannot continue the work.
Using the second way ("UPDATE ...") bring me to the same situation.

François Van Lerberghe
Rue Thier Monty, 15 A
4570 Marchin
Belgium

le 5/10/13 14:03, Joseph Morgan <joseph at checkos.com> a écrit :

> Hi if you are using vserver, shouldn't vserver lock the records for you
automatically? 
> 
>> On Oct 5, 2013, at 1:59 AM, François Van Lerberghe
<frvanlerberghe at gmail.com> wrote:
>> 
>> Hello,
>> 
>> I have a procedure where I update every record of a table (5000 records). In
>> order to do that, I make a VCursor with EVLokType.kReadWrite on the whole
>> table.
>> At the end of this procedure, I call another procedure to update a few
>> records (50) of that same table. This update is in another procedure because
>> it is called by some other places of the project. How must I deal with the
>> records locking in this second Vcusor using the same table, but not the same
>> records ?
>> 
>> 1) If I nil the first Vcursor (locking the whole table) before create the
>> second, locking the needed records, I have a risk (very low I know, but that
>> exist) that, just before I create my second Vcursor, another user lock some
>> records of that table, reading or writing incorrect data and stopping me to
>> complete the work.
>> 
>> 2) Must I keep the first Vcursor ensuring that nobody can modify the table
>> and create the second with kNoLock ? Is it safe to update the records in
>> this second Vcursor ?
>> 
>> 3) I see a third option : Keeping the first cursor. I pass this Vcursor as
>> parameter to iterate, test each record and update the records that meet some
>> condition. I don't like this option as
>> - I prefer sending a second SQL query to retrieve the needed records rather
>> than iterate and test each record
>> - this second procedure is called by some other places of the project
>> 
>> I prefer the second option if it is safe. Could you be kind enough to give
>> me your advice on this ?