Next beta will have record locks.

[Charles Yeomans]

On Monday, June 30, 2003, at 05:26 PM, Ruslan Zasukhin wrote:

> Hi guys,
>
> I want to make small announce of a new Valentina feature -- record  
> locking.
>
> We have add this feature for Valentina Server.
> This was the last feature required to make Vserver usable for real  
> life.
>
> ----------------------------------------------------------------------- 
> ----
> * Locks set a Cursor on creation automatically,
>     and remove locks on destroying.
>
> * Implemented Read and Write locks.
>
> * Manu cursors can set Read (Shared) lock on the same record.
>
> * On a record locked for Read cannot be set Write lock.
>
> * Only one cursor can set Write (Exclusive) lock.
>
> * To Add/Delete/Update records you need cursor that set Write locks.
>
> * Cursor with kForwardOnly parameter will unlock a record when you  
> move to
> next record of cursor.
>
> ----------------------------------------------------------------------- 
> ----
> IMPORTANT:
>     Record locking now is also feature of *ALL* Valentina products,
>     V4RB and V4MD developers already have see that SqlSelect() now
>     have new parameters:
>
>     SqlSelect(query, kClient/kServer, kRead/kWrite,  
> kForwardOnly/kRandom)
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Even if you develop app with local database, starting from new release  
> you
> will need deal with this parameters.
>
> For Local db, kServer amd kClient will be the same of course.
>
> Now you will need CREFULLY set parameter kWrite, when you want a  
> cursor that
> allows modify records. On default cursor will be ReadOnly and  
> ForwardOnly,
> because this is the most friendly set of parameters for multi-user  
> access.
>
> YES, guys, payment for this new feature -- you will need to modify a  
> little
> your current sources even if you do not use Valentina Server.
> Each cursor that want to modify records must be created with kWrite
> parameter.
>
> This feature will allow even to developers of apps with local dbs many
> benefits, for example now you can really safe develop multi-thread  
> apps,
> multi-window apps, where each thread/window have own cursor that can  
> concur
> to others.
>

How persistent are these locks? For instance, suppose my app crashes  
while a record is locked.  Is the lock written to the db, or does it  
just live during the runtime?

Charles Yeomans