I am a former ADS user converting applications to EDB and have run into an issue with Cached Updates.  Previously in ADS I had a RowVersion in many tables and I could use it to manually determine if someone else had changed a row since I had started an edit on temporary data from that row. I could then manually provide an error when they tried to post changes to that row where someone else had changed it first.  It has worked well for me in the past in ADS.  Amoung other things Tim had made mention in another thread of Cached Updates and finally I got to look into in and LOVED IT as essentially I could accomplish the same thing without doing the work myself.  In summary here is what I do:
    - set filter to the one record I want to edit (to reduce the size of the temp table)
    - BeginCachedUpdates on that table
    - call Edit on that table
    - ... take my time editing ...
    - call Post on that table
    - ApplyCachedUpdates (error will be provided if changes have occurred)
    - remove Filter

It had been working fine until it didn't.  In a particular table I kept getting errors "ElevateDB Error #1007 The row has been deleted since last cached for the table Product".  After researching further and guided by a recent bug fix I remembered about Cached Updates and memos, I focused there and this is what I have found.  It doesn't seem to matter if there are memo fields in the table or even in the edit until you edit a memo field as part of a cached update.  After that the error above keeps coming up regardless of whether the memo field is edited.  (btw what I call memo is CLOB)  I have been able to recreate this issue in a table that had been working fine for weeks by adding an edit and creating another problem table.

If I take the cached updates out all works fine except my application doesn't have the advantages of the cached updates.

<< It had been working fine until it didn't.  In a particular table I kept getting errors "ElevateDB Error #1007 The row has been deleted since last cached for the table Product".  After researching further and guided by a recent bug fix I remembered about Cached Updates and memos, I focused there and this is what I have found.  It doesn't seem to matter if there are memo fields in the table or even in the edit until you edit a memo field as part of a cached update.  After that the error above keeps coming up regardless of whether the memo field is edited.  (btw what I call memo is CLOB)  I have been able to recreate this issue in a table that had been working fine for weeks by adding an edit and creating another problem table. >>

Yep, I've reproduced it here, and I'll have a fix out sometime this week.

Tim Young
Elevate Software
www.elevatesoft.com

any updates on this?

Greg,

<< any updates on this? >>

2.27 released yesterday includes the fix for this.

Tim Young
Elevate Software
www.elevatesoft.com