cursor/api

[Ralf Sander]

on 10.02.2005 8:27 mo, Ruslan Zasukhin wrote:

> On 2/10/05 2:55 AM, "Ralf Sander" <ralf at end-if.de> wrote:
> 
>>>> The new api way is much more flexible, Adding records to a found set,
>>>> sorting etc.
>>>> But:
>>>> Because its all based on RecIDs, which will be reused, does this work
>>>> in an multiuser invironment?
>>> 
>>> 1) I see only one problem:
>>> 
>>> API way do not have yet record locks.
>>> I think we need add yet Vtable.Lock()  .Unlock()  functions.
>>> 
>>> Ralf, it is not good idea do not use locks in the mutli-user
>>> environment.
>> 
>> I thougth, I could create my own lock:
>> try to write to "lock" field of record, if "lock" field is empty and no
>> write error, write username to lock field of record...
> 
> But what sense?! You should use built-in locks.
> And Later when we will get transactions develop will not need manually
> control locks. 
What are transactions and when is "later"?
> 
> 
>>> 2) actually Cursor also is based on RecID, just you not see this.
>>> and cursor can/should lock selected records.
>> But a deleted record does no longer contain any data in the cursor,
>> even if the rec id is reused. Is there any build in check?
> 
> The correct way is:
> cursor -- lock its records.
> so issue with deleted record must never happens


The main data for viewing is a thunbnail and the name of a record.
So it makes not really sence for me to prevent a record from viewing,
because anyone is modifying any other field.
The other way round it makes no sence to prevent a record from editing,
because anyone is viewing it.
Will there be problems like crashs if someone trys to get a cursor for a
record, that someone other is editing at the same time or will he simply get
the current state of the record?


Cheers,
Ralf