Next beta will have record locks.

[Ruslan Zasukhin]

on 7/1/03 19:20, erne at ernestogiannotta at tiscalinet.it wrote:

> mmm... I can see big trouble for me in this kind of implementation :-(
> 
> I can see the danger of having a record changed while used by another cursor
> for, say, an account total but the alternative is to store references to the
> records somwhere (a list, an array or whatever) and let go free those
> records.
> 
> But then we'll be on the very same boat, another cursor can change the data
> and our references won't be up-to-date anymore.
> 
> Lots of overhead and memory waste to achieve nothing
> 
> Of course if I don't want my data to be changed while I'm processing them I
> could still want to lock them, but why must this be always forced?
> 
> I'd love much better to have the possibility of having a cursor free of
> locks, then when any of its data gets changed by another cursor those would
> be updated everywhere
> Pretty much as it is now, and a Cursor.Datachanged event would be welcome

Erne,

You are right. In the SQL's transaction levels exists so called
    level "DIRTY READ".

Valentina now works in this DIRTY READ mode in fact.
I think we can add kNoLocks parameter then user get this ability -- see in
one cursors changes made by other cursor.
So far so good. Yes we can easy do this.

Erne, in the same time I want point that although this level 1 "DIRTY READ",
exists in the standard of SQL, most mature DBMS like Oracle, Sybase, SQL
Serve even DO NOT support it. They explain this that this is very danger way
to work with data...

Indeed, this mode of record access can be used in real life only in very
special cases, e.g. You want fastest dump of some records, and you do not
care about consistency of them.

As I see you going to use this mode in your app as the main way.
May be you need rethink your design? :-)


2) I think we will NOT have event Cursor.Datachanged.
 IF you will think about server with 100 users it is too big overhead to
send to each user such event on each change.
You will see changes self on RE-READ of records.

> I'd like also the possibility of set locks on already living cursors
> with methods like
> cursor.LockWrite as Boolean
> cursor.LockRead as Boolean
> cursor.Unlock
> 
> and to be true I'd love also to have this possibility on a record basis
> as in
> 
> cursor.CurrentPosition = 12
> cursor.LockRecordWrite as Boolean
> cursor.LockRecordRead as Boolean
> cursor.UnlockRead
> 
> 
> Am I just dreaming?

What sense, Erne?

> Wouldn't this be like paradise?
> Why can't we fly high?

In fact you ask about LOW LEVEL access :-)

> I remember we talking about even let Valentina take care of all these boring
> tasks in a vodoo magic way!

Problem with such manual record locking is next:

-- so you have cursor
-- server is located on other side of planet.
-- now you start bother network sending a lots of small requests and waiting
confirmation.

You see problem?

Such manual Record locking exists in 4D as I know, btw.

Also note that with manual record locking you will expect failure, and so
you will write "busy loops" -- this is bad technique.

Now, on server side will be locked all needed records and you even do not
need think about this.

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