I would suggest exploring this. The detail is most audits need to know WHO
is changing the data, so you'll need to have an explicit usre login to
Oracle to facilitate this (vs a generic Oracle login that's used to access,
say, a User table for application log in).

We can't use Oracle auditing in our J2EE application because all of our
connections come from a Database pool, and are all logged in as a generic
system wide user.

You CAN however, (as I understand it) associate some "meta data" with a DB
connection that can be audited as well, so it may simply be a matter of
associating the application user login id with each connection, even if you
use a generic Oracle log in. With a Swing app, this would be easily done in
the (I assume) central "get connection" method that most every application
has, and can assoiciate the global login id whenever it returns a
connection. Other wise you need to pass the login id to that getConnection
method every time (which is sort of a pain, and this is why at this juncture
we're STILL not using Oracle auditing, too invasive to make this switch to
our codebase at this point).

Finally, if your code is factored properly, just start dropping "audit"
calls in all of your calls that hit the DB. It's Work, and it's a Pain, but
it does the job.

Regards,

Will Hartung
(willh@msoft.com)