Next beta will have record locks.

[erne]

Hi Ruslan,

on 1-07-2003 20:00, Ruslan Zasukhin at sunshine at public.kherson.ua 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.
> 

pretty please! 8-)

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

I know there are risks, but I want to be allowed to take them

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

well I do care, that is why I'd very much appreciate a Cursor.DataChanged
event... 
as things stand now I have to look up all my cursors to see if they hold a
reference to the record I've just change and run some refresh routine

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

I'll give you a real life example:
I've a browse window resulting from a complex join query and thus not
writeable (that's why I asked you writable join cursors)
User double clicks a cell to edit it
I keep reference to the recid and table of each column in the cursor so I
build a single table editable cursor with the field needed and let the user
edit it, then I issue Update and the data is changed in real time into my
browse window (BTW I could use a SQLExecute to achieve the same, what about
this attempting to modify Locked records?)

Now with the Locked cursor I'd have to destroy the cursor used by the browse
window, perform the update then rebuild the cursor



There's lots of situations like this, I often have cursors living around and
used to be happy with it... actually it is one of the Valentina features I
love most

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

these are good to perform Cursorwide operations in a safe way

>> cursor.LockWrite as Boolean

Now I can perform several updates on the cursor

>> cursor.LockRead as Boolean

Now I can build a report consistent for the time being
(nobody can change data behind by back)

>> cursor.Unlock

Set it free-for-all
Everybody can have access to these data

>> 

>> and to be true I'd love also to have this possibility on a record basis
>> as in
>> 

these are good to perform Record specific operations in a safe way

>> cursor.CurrentPosition = 12
>> cursor.LockRecordWrite as Boolean

Now I can update the record

>> cursor.LockRecordRead as Boolean

Now I can use this record in a calculation consistent for the time being

>> cursor.UnlockRead
>> 

Set it free-for-all
Everybody can have access to this record

>> 
>> Am I just dreaming?
> 
> What sense, Erne?
> 

of course a cursor.CurrentPosition = 12 can involve several records of
different tables

>> Wouldn't this be like paradise?
>> Why can't we fly high?
> 
> In fact you ask about LOW LEVEL access :-)
> 

Well, the LOCK ALWAYS thing looks like a cage to me ;-)

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

to be true no, I could always build a cursor LOCKED if I need to

or write code like

While not myCursor.LockWrite
   if timeout > 5000 then
      Msgbox  "Sorry the server is busy now, try later"
   else
      timeout = timeout + ticks
   end if
end while

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

in FoxPro also

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

it's just the same in

c = DB.SqlSelect(query, kClient, kWrite, kRandom)
While c = nil 
   if timeout > 5000 then
      Msgbox  "Sorry the server is busy now, try later"
   else
      timeout = timeout + ticks
   end if
   c = DB.SqlSelect(query, kClient, kWrite, kRandom)
end while

what difference here?

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

no, you can't even get your cursor now if somebody else has it even for READ
only!



Cool Runnings,
Erne.

-- 
|  e r  |  Ernesto Giannotta
|  n e  |  Musical Box - a media store