Brian: Your comments suggest to me that you are accustomed to an archiving model that is entirely different from RAP's archiving model, and that you are presuming that RAP works in the same way. I imagine that you are accustomed to the traditional model in which all versions of every record are stored in the same table as the most recent version, and in which queries for a given record must go looking for the most recent one based on the records' AuditDates, and that "deleted" records are merely marked for deletion rather than actually being deleted. In this model deleted records can be brought back to life by simply unmarking them. If this is your view of the RAP model, then I ask that you reread the article carefully and also reread the code sample carefully.

In the RAP model, each conceptual table is really two tables: a "current" table that stores only current records, and an "archive" table that stores a log of every version of every record. Queries for current data look only in the "current" table, where they will find only current records. Such queries never have to check for AuditDates because there is always exactly one version of every record in the "current" table, namely the current version. Queries for current data also never need to check for "deleted" flags because records in the "current" table are, by definition, not deleted.

Queries for current data never look in the "archive" table. The only purpose of the "archive" table is to store past versions of every record for the purpose of reconstructing snapshots of past data as of a given time (for example seeing a report or your application screens as they would have appeared six months ago). There is no need to incorporate any sense of the current time (i.e. the time at which the query is executed) because such data is timeless. There is no reason for a query into this table using a future AsOf date to return anything other than what it currently returns, which is the last recorded version of every record that hasn't been deleted yet.

While it would be possible to reconstruct a new record in the "current" table containing the same business key (and other data) as a previously deleted record, that reconstructed record would necessarily have a new surrogate key (since SQL Server properly would not allow us to reuse a surrogate key in the "current" table) and as such, from the perspective of the "archive" table, that reconstructed record would be a new record (since it has a new key) and not part of the old record's audit trail.

There is no way for RAP to "undelete" a record in the manner you describe because RAP does not delete records by marking them. Rather it deletes records by actually deleting them from the "current" table. The corresponding record with the "D" flag in the "archive" table is merely a historical marker indicating when the lifetime of the record ended. Since queries for current data never look in the "archive" table, and since snapshot queries (i.e. queries with a non-null AsOf date) intentionally never return deleted records, the data in a "D" record is never returned in a query, nor is it intended to be returned.

If you reread the article carefully, I think you will find that the RAP model for creating, updating, deleting, and querying data is radically different from what you are imagining. It is intentionally designed to be radically different, and I am hoping you will agree that this intentionally different design is radically better.