Had you considered just turning on the audit_trail to db_extended or some such, along with a trigger or two to apply any additional information you need? I dont think the extended audit trail would actually be lacking much information, as I recall it even contains the undo sql. On Wed, Mar 4, 2009 at 11:17 AM, Bill Ferguson <wbfergus@xxxxxxxxx> wrote: > The only other database available is one where they want an exact > duplicate of this one I have here in Denver (the other is in Reston, > VA), and we're trying to use Shareplex to accomplish that goal. So any > changes here are (almost instantly) replicated to the other system, > and vice versa, so tracking the changes becomes even more problematic, > as an extra check needs to made to exclude replication changes. > > Each data table already has basic info, update_date, updated_by, > insert_date, inserted_by. I also have a procedure fired off through a > trigger, so whenever a change is made, the procedure loops through all > the tables for that 'master' record and generates a XML-type CLOB > field of the previous version of all the data before the change. With > this, it's easy for me design something similar to how Wikipedia > tracks and displays changes, with the added benefit of seeing > everything in context, not merely the new and old vlaues of a field. > > > -- > -- Bill Ferguson > > On Wed, Mar 4, 2009 at 9:17 AM, Christo Kutrovsky > <kutrovsky.oracle@xxxxxxxxx> wrote: > > What about using Oracle Streams ? Or if not possible use logminer. > > > > You would only have to dump some extra info in the transaction to > > 'bind it' to a specific user. > > > > -- > > Christo Kutrovsky > > Senior DBA > > The Pythian Group - www.pythian.com > > I blog at http://www.pythian.com/blogs/ > -- > http://www.freelists.org/webpage/oracle-l > > > -- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.'