Next beta will have record locks.

[erne]

Hi Ruslan,

on 2-07-2003 11:25, Ruslan Zasukhin at sunshine at public.kherson.ua wrote:

> on 7/2/03 11:52, erne at ernestogiannotta at tiscalinet.it wrote:
> 
>>> 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?)
> 
> Erne, this is NOT how works big mature RDBMS as far as I know.
> Only Access have cursor which mirrow changes.
> 

yep, I admittedly have no confidence with those big ones
and of course they have reasons to choose their ways

I also thought however that Valentina has a mind of her own and can decide
what's best without having to mimic any big guy's behaviour
(OK! a low attempt to appeal to your well known sense of pride 8-)

> You can easy see why it is not possible, if you note, that multi-table join
> many RDBMS build as other tmp table. So your Update change original table,
> but this do not affect your tmp table of join cursor.
> 

mmm... difficult yes, but not impossible
after all to implement the lock feature you must have a list of the used
recid somewhere and maybe you also may keep track of where they are and keep
them mantained

Am I asking too much?

A cursor.DataChanged event would be feasible then and let us care of update
it?

> 
>> Now with the Locked cursor I'd have to destroy the cursor used by the browse
>> window, perform the update then rebuild the cursor
> 
> Yes, this is how works big RDBMS that assume that system can have a lots of
> users connected.
> 

I can understand this (take the data and run)

> Access that allow such runtime update of cursor is NOT intended for use in
> big groups of users.  This is why they can allow self this behavior.
> 
> Well, assuming that Valentina is used for both local db development and
> remote db I think we really should support both ways. And this is
> responsibility of Valentina Developer use tools correctly.
> 

exactly as I thought, Valentina goes big
but don't let us small faithful lovers down

>> 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
> 
> And this feature will get a lots of criticism from Developers used to Oracle
> and Sybase. 
> 

You never can please everyone 8^)

> By transaction rule:
> actions of one user should not be visible to other users until he
> commit transaction...
> 
> ---------
> I have hear that SQL Server allow modify some columns of multi-table JOIN
> cursor, but only columns that belong to Table 'MANY'.
> I agree with this, and with sure this also will be added to Valentina ...
> Although then we must be able ask each column if it can be modified.
> 
> Example: JOIN of    Person and Phone tables
> 1   :  M
> 
> You get cursor where e.g. name 'Erne' repeated 5 times with different
> phones. Sql Server allow you in this cursor update phone number, i.e. Fields
> from MANY table. But we cannot update in one record name 'erne', because
> then we break consistency -- rest 4 records still will have 'Erne'
> 
> So I wonder, if such RULE will satisfy your task?
> Do you change in your app only MANY table columns ?
> 

Nope! If I change the 1 table column then all occurrences get the change
and BTW in some app I have mostly linkers for M : M relations
(I remember some talk on having this as automatic for future)


Now I know dreams can be achieved only step by step and this takes time and
priorities rule but, please, don't throw away what we already have and are
happy with!

(and never stop dreaming!  :-)



Cool Runnings,
Erne.

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