Ed Leafe wrote: > On Apr 16, 2008, at 11:34 PM, Carl Karsten wrote: > >> I can see 2 reasonable was to implement it: >> >> 1. list of deleted items. >> 2. "deleted" virtual field. >> >> In both cases, you are storing something, and committing it later. > > > These are both highly problematic. Using database transactions is > much cleaner.
Except Uwe's point is well-taken: database transactions shouldn't be kept open for a potentially long time. I don't understand the deleted virtual field idea: I don't want to expose the deleted records at all. But I'm trying to understand why a list of deleted items would be highly problematic - I just don't see how it would be much different than the memento list of changed fields or new records. So when a record is deleted, here's what I think should happen: + the record moved from cursor.records to cursor.deleted (delete the record from cursor.records completely, resulting in adjusted RowCount). cursor.deleted also saves the original RowNumber. + biz will have to iterate children of the deleted item to also delete those, if referential integrity is set to CASCADE. Or forbid the delete if RESTRICT. Or not cascade if IGNORE. + on cancel(), deleted records are moved back, and we attempt to put them back in the original position in the recordset. + on save(), DELETE statements are executed for the records in the deleted list, and the deleted list cleared. + functions like isAnyChanged() take into account the existence of records marked for deletion. I know this is easier said than done. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
