Hi Cristian,

"Dirty" record is a record that is changed or appended, but the change is not saved into table or into table buffer (this happens if cursor is in row or table buffering mode). The easiest way to save the record into table or into table buffer is to try to move from that record: SKIP, GO RECNO(), ...

When focus stays in the grid, it maintains it's own current record. After custom code has been executed, grid moves pointer back to that record, but that doesn't save changes for any other record that has been left "dirty" by the custom code (different record is modified or appended). Those changes are left cached only in memory until the "dirty" record becomes the current record again. The error is reported when there is a cached "dirty" record and an attempt to modify another record is made.

Are you able to reproduce the error consistently?

Thanks,
Aleksey.



>The parent table has a readonly grid on page2 of a pageframe - for searcing - and child table is updated in grid - i think this is clasical; the code to append record is of course in methods of form and called from buttons, toolbar or menu
>What do you meen with and why cursor can be "dirty"?
>Should i put tablebuffer on both parent and child and do "go record recno()" to eliminate that "dirty"?
>
>And for second problem with fox catching first the errors?
>
>
>>Hi Cristian,
>>
>>Are you doing in a grid something similar to what I described as "illegal"?
>>Have you tried the workaround I suggested? Does it help?
>>
>>If it doesn't help, please provide a repro code and I will take a look.
>>
>>Thanks,
>>Aleksey.
>>
>>>Hi,
>>>
>>>Both errors "Cursor cannot de modified..." and "File is in use by another" is happening to my apps allmost every day on ~7 records from 250. This is an old (since VFP 3.0) problem. In later time I get bad references form users who can't find his recently addeded recs!
>>>In addition to this errors i experienced an additional behaviour:
>>>-one user append and save an document made of parent and child records
>>>-second user append blank records in tables buffers
>>>-second user edit this records
>>>-second user try to save
>>>from now on sometimes the tableupdate() gets the records from second user over records from first user; even on appended records the update trigger is executed instead of insert trigger; i am very shure of this because i added an audit table in wich is recorded every modification of tables by triggers.
>>>
>>>This problems seems to me strong related and is definitely a BUG.
>>>
>>>From my observation this is happening to a user that stay longer on appended records (wich is in buffers and can not be saved as you sugest because triggers will fail with wrong data) and meenwhile other user are doing append and save.
>>>
>>>I tryed over time many workarrounds but with no effect:
>>>1. reccount() to refresh header before tableupdate()
>>>2. flock() or rlock("0") to stop other doing same time modification - to be sure automatic lock dosent fail - and as an side effect get trigger errors trapped by fox wich is showing his own error message and then by error routine in my code/form -> THIS IS ANOTHER BUG
>>>3. save as soon as posibble the parent records to not stay until child records are completed - this reduce the frequency but not eliminate the problem
>>>
>>>It is hard and annoying to do data input with this errors!
>>>
>>>Thanks and hope this can be fixed.