Re: NewEra 3.1: Several problems

In article <3470A44E.6D0D@net.HCC.nl>, Henk van der Geld <H.van.der.Geld@net.HCC.nl> writes >Hi NewEra folks, > >Next are some problems I came across when using NewEra 3.1 TC1. >I would like the people who read this message to give relevant response >(acknowledge, agree, disagree). > >Here they come: > >1. NULL object in executable result in unusefull message >SNIP > >2. DataState of superField influences the outcome of >ixSuperField::isPrimaryKey() >SNIP >3. Edit-operation in readOnly superField causes ixSuperTable::lockRow() >SNIP I sympathise! You can forget pessimistic locking. If you change a record in a dataset, when you move to the next record the previous one is updated and unlocked when you do a commit. If you don't want to update the record you can return false in the beforeapply event. Unfortunately your dataset now becomes un-updateable and the original record is still locked. Best bet is to re-instate the original data on the previous record and let it update with the original data thus unlocking when it commits. However if the original record was actually re-read because of a staledata event then you can't re-instate the record back to its re- read state. Any changes you make cannot be restored! I defy anyone to produce some code that allows you to browse through a (pessimistic locked) dataset, re_instate the record if you have made a mistake, lock and unlock records correctly, and respond to staledata events if they occur! Best of Luck -- Mike Ripley