|
Auditing Best Practice
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
Auditing Best Practice
by joen
::
Rate this Message:
Hello PinoyJuggers,
I am assigned a task to add auditing capabilities to an existing application with the following technology stack: Java EE 5, (EJB 3), Oracle 10g. So from your experience, what sort of information is in your Audit DBs? Obviously, there are the user name, the date, the data that was going to be changed (if it's a process that will change data). In your experience, what other information have you stored? Do you store a snapshot of the original data also? Joen |
|
|
Re: Auditing Best Practice
by Giancarlo Angulo
::
Rate this Message:
yes definitely.
===== ANGOL ===== -----|-^_^X@^_^, =====|+^_^X++~_~,@----- "The only thing worse than a hopeless romantic is a hopeful one" Magbasa bago Mamuna. Mag-isip bago mambatikos Without Truth there is no Justice, Without Justice, there is Tyranny Semper fi Proof of Desire is Pursuit www.onthe8spot.com igan.long@... 09173822367 On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno <joenmoreno@...>wrote: > > > Hello PinoyJuggers, > > I am assigned a task to add auditing capabilities to an existing > application with the following technology stack: Java EE 5, (EJB 3), > Oracle 10g. So from your experience, what sort of information is in > your Audit DBs? Obviously, there are the user name, the date, the > data that was going to be changed (if it's a process that will change > data). > > In your experience, what other information have you stored? Do you > store a snapshot of the original data also? > > Joen > > |
|
|
Re: Auditing Best Practice
by Jeff Gutierrez
::
Rate this Message:
Joen,
The question you should be asking yourself is: What information would your business need to find out what was changed, who changed it, at what time, and for what (very important.) Answers to those questions would lead you to the information to store. User name, date, action, old data, and new data are common fields. I typically don't have foreign keys and cascade actions in the audit trail record. (I usually copy the user name.) This way you get a true historical information. HTH Jeff On Wed, Oct 14, 2009 at 10:20 AM, Joselito D. Moreno <joenmoreno@...>wrote: > Hello PinoyJuggers, > > I am assigned a task to add auditing capabilities to an existing > application with the following technology stack: Java EE 5, (EJB 3), > Oracle 10g. So from your experience, what sort of information is in > your Audit DBs? Obviously, there are the user name, the date, the > data that was going to be changed (if it's a process that will change > data). > > In your experience, what other information have you stored? Do you > store a snapshot of the original data also? > > Joen > > > ------------------------------------ > > Yahoo! Groups Links > > > > |
|
|
Re: Auditing Best Practice
by Juanito Calingacion
::
Rate this Message:
perhaps it would help to know the type of industry the company is in.
JC On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno <joenmoreno@...>wrote: > > > Hello PinoyJuggers, > > I am assigned a task to add auditing capabilities to an existing > application with the following technology stack: Java EE 5, (EJB 3), > Oracle 10g. So from your experience, what sort of information is in > your Audit DBs? Obviously, there are the user name, the date, the > data that was going to be changed (if it's a process that will change > data). > > In your experience, what other information have you stored? Do you > store a snapshot of the original data also? > > Joen > > |
|
|
Re: Auditing Best Practice
by joen
::
Rate this Message:
Well, my question is a generic one. It's more like what "usually" do you
include when auditing? Do you also include the before snapshot of the data that is going to be changed? To answer your question, it's in the prepaid card processing industry. Joen On Thu, Oct 15, 2009 at 9:55 AM, Giancarlo Angulo <igan.long@...>wrote: > > > yes definitely. > ===== > ANGOL > ===== > -----|-^_^X@^_^, =====|+^_^X++~_~,@----- > > "The only thing worse than a hopeless romantic is a hopeful one" > > Magbasa bago Mamuna. Mag-isip bago mambatikos > > Without Truth there is no Justice, > Without Justice, there is Tyranny > > Semper fi > > Proof of Desire is Pursuit > > www.onthe8spot.com > igan.long@... > 09173822367 > > > On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno <joenmoreno@... > > wrote: > >> >> >> Hello PinoyJuggers, >> >> I am assigned a task to add auditing capabilities to an existing >> application with the following technology stack: Java EE 5, (EJB 3), >> Oracle 10g. So from your experience, what sort of information is in >> your Audit DBs? Obviously, there are the user name, the date, the >> data that was going to be changed (if it's a process that will change >> data). >> >> In your experience, what other information have you stored? Do you >> store a snapshot of the original data also? >> >> Joen >> > > > |
|
|
Re: Auditing Best Practice
by joen
::
Rate this Message:
Hi Jeff,
Sorry for the late reply. Thanks for that answer. That's exactly what I was wondering, whether or not to include the original data. Sounds like in your experience, it is normal to include such data. My requirement does require to include the original and the new data. At first, it felt wrong because it's (possibly) going to be a lot of (duplicated) data. However, I have softened that concern because as you have pointed out, audit data is truly a historic set of records (with legal ramifications). So absolutely I agree with you that there will be no foreign keys and cascades on the Audit tables. My next concern is the possible performance hit the application will take when introducing Auditing. I am concerned particularly because of the fact that I have to introduce 2 extra calls to the repository (which could be a DB call or a web service call) in each of the "user activities" that would require auditng. First is the call to get the original data of the information to be changed, and second the actual persisting of the Audit information. The second part could be alleviated a little bit by making Audit persistence calls asynchronous. The first part however will now be part of the original transaction. How were you able to handle that? Or is this part and parcel of Auditing and I'm just being paranoid? Thanks, Joen On Thu, Oct 15, 2009 at 1:06 PM, Jeff Gutierrez <jeff@...> wrote: > > > Joen, > > The question you should be asking yourself is: What information would your > business need to find out what was changed, who changed it, at what time, > and for what (very important.) Answers to those questions would lead you to > the information to store. User name, date, action, old data, and new data > are common fields. > > I typically don't have foreign keys and cascade actions in the audit trail > record. (I usually copy the user name.) This way you get a true historical > information. > > HTH > Jeff > > > On Wed, Oct 14, 2009 at 10:20 AM, Joselito D. Moreno < > joenmoreno@...> wrote: > >> Hello PinoyJuggers, >> >> I am assigned a task to add auditing capabilities to an existing >> application with the following technology stack: Java EE 5, (EJB 3), >> Oracle 10g. So from your experience, what sort of information is in >> your Audit DBs? Obviously, there are the user name, the date, the >> data that was going to be changed (if it's a process that will change >> data). >> >> In your experience, what other information have you stored? Do you >> store a snapshot of the original data also? >> >> Joen >> >> >> ------------------------------------ >> >> Yahoo! Groups Links >> >> >> >> > > |
|
|
Re: Auditing Best Practice
by Juanito Calingacion
::
Rate this Message:
For some industries, editing a transaction record after a mistake is not
allowed. The transaction record is tagged as being corrected and the correct transaction record must be encoded. Both transactions are printed on the ledger for instance. In manual accounting, one is allowed to correct an entry in a ledger/journal by simply crossing the field to be corrected with a line. This way the original entry is still visible - so snopake/whiteout is not allowed (read: no cover-up). For usual auditing - the transaction record should be traceable to the "source" e.g. department/user/authority/device/ip/physical location, reference numbers which are usually coded, documents/screens are numbered/coded for reference. I recall one business owner talked about coding scheme that embeds all this information i.e. you could tell where (say branch/warehouse) the item is from, its product category,etc. So you could just about put a lot of information to make it traceable to the source. JC On Sat, Oct 17, 2009 at 3:36 AM, Joselito D. Moreno <joenmoreno@...>wrote: > > > Well, my question is a generic one. It's more like what "usually" do > you include when auditing? Do you also include the before snapshot of the > data that is going to be changed? > > To answer your question, it's in the prepaid card processing industry. > > Joen > > > On Thu, Oct 15, 2009 at 9:55 AM, Giancarlo Angulo <igan.long@...>wrote: > >> >> >> yes definitely. >> ===== >> ANGOL >> ===== >> -----|-^_^X@^_^, =====|+^_^X++~_~,@----- >> >> "The only thing worse than a hopeless romantic is a hopeful one" >> >> Magbasa bago Mamuna. Mag-isip bago mambatikos >> >> Without Truth there is no Justice, >> Without Justice, there is Tyranny >> >> Semper fi >> >> Proof of Desire is Pursuit >> >> www.onthe8spot.com >> igan.long@... >> 09173822367 >> >> >> On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno < >> joenmoreno@...> wrote: >> >>> >>> >>> Hello PinoyJuggers, >>> >>> I am assigned a task to add auditing capabilities to an existing >>> application with the following technology stack: Java EE 5, (EJB 3), >>> Oracle 10g. So from your experience, what sort of information is in >>> your Audit DBs? Obviously, there are the user name, the date, the >>> data that was going to be changed (if it's a process that will change >>> data). >>> >>> In your experience, what other information have you stored? Do you >>> store a snapshot of the original data also? >>> >>> Joen >>> >> >> > > |
|
|
Re: Auditing Best Practice
by joen
::
Rate this Message:
Yes, we are one of the industries that have specific rules (actually, laws)
about not changing audit records. Alrighty then, I should stop worrying about large amounts of data and just make sure auditing process is as performant as it could be. Thanks for the input. Joen On Mon, Oct 19, 2009 at 8:02 PM, Juanito Calingacion < juanito.calingacion@...> wrote: > > > For some industries, editing a transaction record after a mistake is not > allowed. > The transaction record is tagged as being corrected and the correct > transaction > record must be encoded. Both transactions are printed on the ledger for > instance. > In manual accounting, one is allowed to correct > an entry in a ledger/journal by simply crossing the field to be corrected > with a line. > This way the original entry is still visible - so snopake/whiteout is not > allowed > (read: no cover-up). > > For usual auditing - the transaction record should be traceable to the > "source" > e.g. department/user/authority/device/ip/physical location, > reference numbers which are usually > coded, documents/screens are numbered/coded for reference. I recall one > business > owner talked about coding scheme that embeds all this information i.e. > you could tell where (say branch/warehouse) the item is from, its product > category,etc. > So you could just about put a lot of information to make it traceable to > the source. > > > JC > > > > On Sat, Oct 17, 2009 at 3:36 AM, Joselito D. Moreno <joenmoreno@...>wrote: > >> >> > > >> Well, my question is a generic one. It's more like what "usually" do >> you include when auditing? Do you also include the before snapshot of the >> data that is going to be changed? >> >> To answer your question, it's in the prepaid card processing industry. >> >> Joen >> >> >> On Thu, Oct 15, 2009 at 9:55 AM, Giancarlo Angulo <igan.long@...>wrote: >> >>> >>> >>> yes definitely. >>> ===== >>> ANGOL >>> ===== >>> -----|-^_^X@^_^, =====|+^_^X++~_~,@----- >>> >>> "The only thing worse than a hopeless romantic is a hopeful one" >>> >>> Magbasa bago Mamuna. Mag-isip bago mambatikos >>> >>> Without Truth there is no Justice, >>> Without Justice, there is Tyranny >>> >>> Semper fi >>> >>> Proof of Desire is Pursuit >>> >>> www.onthe8spot.com >>> igan.long@... >>> 09173822367 >>> >>> >>> On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno < >>> joenmoreno@...> wrote: >>> >>>> >>>> >>>> Hello PinoyJuggers, >>>> >>>> I am assigned a task to add auditing capabilities to an existing >>>> application with the following technology stack: Java EE 5, (EJB 3), >>>> Oracle 10g. So from your experience, what sort of information is in >>>> your Audit DBs? Obviously, there are the user name, the date, the >>>> data that was going to be changed (if it's a process that will change >>>> data). >>>> >>>> In your experience, what other information have you stored? Do you >>>> store a snapshot of the original data also? >>>> >>>> Joen >>>> >>> >>> >> > > |
|
|
Re: Auditing Best Practice
by Allan Tan
::
Rate this Message:
UserId Date and Time Table Name Unique Record Id Changes made. (Add, edit, delete, or view). For edit you need to include the old value and new value. We store this in a single string field and written in a human readable manner. (e.g. Changed name from "Java" to ".Net"). ________________________________ From: Joselito D. Moreno <joenmoreno@...> To: pinoyjug@... Sent: Wed, October 21, 2009 2:06:38 AM Subject: Re: [pinoyjug] Auditing Best Practice Yes, we are one of the industries that have specific rules (actually, laws) about not changing audit records. Alrighty then, I should stop worrying about large amounts of data and just make sure auditing process is as performant as it could be. Thanks for the input. Joen On Mon, Oct 19, 2009 at 8:02 PM, Juanito Calingacion <juanito.calingacion @gmail.com> wrote: > > > > > > > > > > > > > >> >For some industries, editing a transaction record after a mistake is not allowed. >The transaction record is tagged as being corrected and the correct transaction >record must be encoded. Both transactions are printed on the ledger for instance. >> > > > In manual accounting, one is allowed to correct >an entry in a ledger/journal by simply crossing the field to be corrected with a line. >This way the original entry is still visible - so snopake/whiteout is not allowed >> > > >(read: no cover-up). > >For usual auditing - the transaction record should be traceable to the "source" >e.g. department/user/ authority/ device/ip/ physical location, >reference numbers which are usually >> > > >coded, documents/screens are numbered/coded for reference. I recall one business >owner talked about coding scheme that embeds all this information i.e. >you could tell where (say branch/warehouse) the item is from, its product category,etc. >> > > >So you could just about put a lot of information to make it traceable to the source. > > >JC > > > > >On Sat, Oct 17, 2009 at 3:36 AM, Joselito D. Moreno <joenmoreno@gmail. com> wrote: > >>> >> >> >> >> >> >> >> >> >> >> > >>> >> >>>> >>Well, my question is a generic one. It's more like what "usually" do you include when auditing? Do you also include the before snapshot of the data that is going to be changed? >> >>>> >> >> >>To answer your question, it's in the prepaid card processing industry. >> >>Joen >> >> >> >>On Thu, Oct 15, 2009 at 9:55 AM, Giancarlo Angulo <igan.long@gmail. com> wrote: >> >>>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>>>> >>>yes definitely. >>>===== >>>ANGOL >>>===== >>>-----|-^_^X@ ^_^, =====|+^_^X+ +~_~,@--- -- >>> >>>"The only thing worse than a hopeless romantic is a hopeful one" >>> >>>Magbasa bago Mamuna. Mag-isip bago mambatikos >>> >>>Without Truth there is no Justice, >>>Without Justice, there is Tyranny >>> >>>Semper fi >>> >>>Proof of Desire is Pursuit >>> >>>www.onthe8spot. com >>>igan.long@gmail. com >>>>>> >>> >>> >>> >>> >>> >>> >>>09173822367 >>> >>> >>> >>>On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno <joenmoreno@gmail. com> wrote: >>> >>>>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>>>> >>>>Hello PinoyJuggers, >>>> >>>>>>>>I am assigned a task to add auditing capabilities to an existing >>>>>>>>application with the following technology stack: Java EE 5, (EJB 3), >>>>>>>>Oracle 10g. So from your experience, what sort of information is in >>>>>>>>your Audit DBs? Obviously, there are the user name, the date, the >>>>>>>>data that was going to be changed (if it's a process that will change >>>>>>>>data). >>>> >>>>>>>>In your experience, what other information have you stored? Do you >>>>>>>>store a snapshot of the original data also? >>>> >>>>>>>>Joen >>>> >>> >> > |
|
|
Re: Auditing Best Practice
by joen
::
Rate this Message:
Hello Allan,
That single string field is an interesting way of doing it. In my case, it wouldn't be too practical to do it the same way because we are auditing service calls that could change entities that have very deep hierarchy. This means that a single service call could cause changes to a lot of entities. That will be either a very long sentence, or a long paragraph of sentences. My plan is to create an Audit (one-to-many) Audit Changes tables with the following info: Audit Table 1) User Id 2) Timestamp 3) Action Name Audit Changes Table 1) audit_fk 2) Name of Property that changed 3) Entity Name (or table name. Not sure yet) 4) Type of the Property 5) Old Value 6) New Value 7) Entity ID Joen On Thu, Oct 22, 2009 at 8:52 AM, Allan Tan <allanctan@...> wrote: > > > > UserId > Date and Time > Table Name > Unique Record Id > Changes made. (Add, edit, delete, or view). For edit you need to include > the old value and new value. We store this in a single string field and > written in a human readable manner. (e.g. Changed name from "Java" to > ".Net"). > > ------------------------------ > *From:* Joselito D. Moreno <joenmoreno@...> > *To:* pinoyjug@... > *Sent:* Wed, October 21, 2009 2:06:38 AM > *Subject:* Re: [pinoyjug] Auditing Best Practice > > > > Yes, we are one of the industries that have specific rules (actually, laws) > about not changing audit records. > > Alrighty then, I should stop worrying about large amounts of data and just > make sure auditing process is as performant as it could be. > > Thanks for the input. > > Joen > > On Mon, Oct 19, 2009 at 8:02 PM, Juanito Calingacion <juanito.calingacion > @gmail.com <juanito.calingacion@...>> wrote: > >> >> >> For some industries, editing a transaction record after a mistake is not >> allowed. >> The transaction record is tagged as being corrected and the correct >> transaction >> record must be encoded. Both transactions are printed on the ledger for >> instance. >> In manual accounting, one is allowed to correct >> an entry in a ledger/journal by simply crossing the field to be corrected >> with a line. >> This way the original entry is still visible - so snopake/whiteout is not >> allowed >> (read: no cover-up). >> >> For usual auditing - the transaction record should be traceable to the >> "source" >> e.g. department/user/ authority/ device/ip/ physical location, >> reference numbers which are usually >> coded, documents/screens are numbered/coded for reference. I recall one >> business >> owner talked about coding scheme that embeds all this information i.e. >> you could tell where (say branch/warehouse) the item is from, its product >> category,etc. >> So you could just about put a lot of information to make it traceable to >> the source. >> >> >> JC >> >> >> >> On Sat, Oct 17, 2009 at 3:36 AM, Joselito D. Moreno <joenmoreno@gmail. >> com <joenmoreno@...>> wrote: >> >>> >>> >> >> >>> Well, my question is a generic one. It's more like what "usually" do >>> you include when auditing? Do you also include the before snapshot of the >>> data that is going to be changed? >>> >>> To answer your question, it's in the prepaid card processing industry. >>> >>> Joen >>> >>> >>> On Thu, Oct 15, 2009 at 9:55 AM, Giancarlo Angulo <igan.long@gmail. com<igan.long@...> >>> > wrote: >>> >>>> >>>> >>>> yes definitely. >>>> ===== >>>> ANGOL >>>> ===== >>>> -----|-^_^X@ ^_^, =====|+^_^X+ +~_~,@--- -- >>>> >>>> "The only thing worse than a hopeless romantic is a hopeful one" >>>> >>>> Magbasa bago Mamuna. Mag-isip bago mambatikos >>>> >>>> Without Truth there is no Justice, >>>> Without Justice, there is Tyranny >>>> >>>> Semper fi >>>> >>>> Proof of Desire is Pursuit >>>> >>>> www.onthe8spot. com <http://www.onthe8spot.com> >>>> igan.long@gmail. com <igan.long@...> >>>> 09173822367 >>>> >>>> >>>> On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno <joenmoreno@gmail. >>>> com <joenmoreno@...>> wrote: >>>> >>>>> >>>>> >>>>> Hello PinoyJuggers, >>>>> >>>>> I am assigned a task to add auditing capabilities to an existing >>>>> application with the following technology stack: Java EE 5, (EJB 3), >>>>> Oracle 10g. So from your experience, what sort of information is in >>>>> your Audit DBs? Obviously, there are the user name, the date, the >>>>> data that was going to be changed (if it's a process that will change >>>>> data). >>>>> >>>>> In your experience, what other information have you stored? Do you >>>>> store a snapshot of the original data also? >>>>> >>>>> Joen >>>>> >>>> >>>> >>> >> > > |
|
|
Re: Auditing Best Practice
by JonT-3
::
Rate this Message:
In my current project, auditting is implemented as two-fold UsageLog and EventLogs. May CLOB field to contain details of user's request including parameters that maybe very long (for usage) and old-new info for events (like update process).
--- In pinoyjug@..., "Joselito D. Moreno" <joenmoreno@...> wrote: > > Hello Allan, > > That single string field is an interesting way of doing it. In my case, it > wouldn't be too practical to do it the same way because we are auditing > service calls that could change entities that have very deep hierarchy. > This means that a single service call could cause changes to a lot of > entities. That will be either a very long sentence, or a long paragraph of > sentences. My plan is to create an Audit (one-to-many) Audit Changes tables > with the following info: > > Audit Table > 1) User Id > 2) Timestamp > 3) Action Name > > Audit Changes Table > 1) audit_fk > 2) Name of Property that changed > 3) Entity Name (or table name. Not sure yet) > 4) Type of the Property > 5) Old Value > 6) New Value > 7) Entity ID > > Joen > > On Thu, Oct 22, 2009 at 8:52 AM, Allan Tan <allanctan@...> wrote: > > > > > > > > > UserId > > Date and Time > > Table Name > > Unique Record Id > > Changes made. (Add, edit, delete, or view). For edit you need to include > > the old value and new value. We store this in a single string field and > > written in a human readable manner. (e.g. Changed name from "Java" to > > ".Net"). > > > > ------------------------------ > > *From:* Joselito D. Moreno <joenmoreno@...> > > *To:* pinoyjug@... > > *Sent:* Wed, October 21, 2009 2:06:38 AM > > *Subject:* Re: [pinoyjug] Auditing Best Practice > > > > > > > > Yes, we are one of the industries that have specific rules (actually, laws) > > about not changing audit records. > > > > Alrighty then, I should stop worrying about large amounts of data and just > > make sure auditing process is as performant as it could be. > > > > Thanks for the input. > > > > Joen > > > > On Mon, Oct 19, 2009 at 8:02 PM, Juanito Calingacion <juanito.calingacion > > @gmail.com <juanito.calingacion@...>> wrote: > > > >> > >> > >> For some industries, editing a transaction record after a mistake is not > >> allowed. > >> The transaction record is tagged as being corrected and the correct > >> transaction > >> record must be encoded. Both transactions are printed on the ledger for > >> instance. > >> In manual accounting, one is allowed to correct > >> an entry in a ledger/journal by simply crossing the field to be corrected > >> with a line. > >> This way the original entry is still visible - so snopake/whiteout is not > >> allowed > >> (read: no cover-up). > >> > >> For usual auditing - the transaction record should be traceable to the > >> "source" > >> e.g. department/user/ authority/ device/ip/ physical location, > >> reference numbers which are usually > >> coded, documents/screens are numbered/coded for reference. I recall one > >> business > >> owner talked about coding scheme that embeds all this information i.e. > >> you could tell where (say branch/warehouse) the item is from, its product > >> category,etc. > >> So you could just about put a lot of information to make it traceable to > >> the source. > >> > >> > >> JC > >> > >> > >> > >> On Sat, Oct 17, 2009 at 3:36 AM, Joselito D. Moreno <joenmoreno@gmail. > >> com <joenmoreno@...>> wrote: > >> > >>> > >>> > >> > >> > >>> Well, my question is a generic one. It's more like what "usually" do > >>> you include when auditing? Do you also include the before snapshot of the > >>> data that is going to be changed? > >>> > >>> To answer your question, it's in the prepaid card processing industry. > >>> > >>> Joen > >>> > >>> > >>> On Thu, Oct 15, 2009 at 9:55 AM, Giancarlo Angulo <igan.long@gmail. com<igan.long@...> > >>> > wrote: > >>> > >>>> > >>>> > >>>> yes definitely. > >>>> ===== > >>>> ANGOL > >>>> ===== > >>>> -----|-^_^X@ ^_^, =====|+^_^X+ +~_~,@--- -- > >>>> > >>>> "The only thing worse than a hopeless romantic is a hopeful one" > >>>> > >>>> Magbasa bago Mamuna. Mag-isip bago mambatikos > >>>> > >>>> Without Truth there is no Justice, > >>>> Without Justice, there is Tyranny > >>>> > >>>> Semper fi > >>>> > >>>> Proof of Desire is Pursuit > >>>> > >>>> www.onthe8spot. com <http://www.onthe8spot.com> > >>>> igan.long@gmail. com <igan.long@...> > >>>> 09173822367 > >>>> > >>>> > >>>> On Wed, Oct 14, 2009 at 11:20 PM, Joselito D. Moreno <joenmoreno@gmail. > >>>> com <joenmoreno@...>> wrote: > >>>> > >>>>> > >>>>> > >>>>> Hello PinoyJuggers, > >>>>> > >>>>> I am assigned a task to add auditing capabilities to an existing > >>>>> application with the following technology stack: Java EE 5, (EJB 3), > >>>>> Oracle 10g. So from your experience, what sort of information is in > >>>>> your Audit DBs? Obviously, there are the user name, the date, the > >>>>> data that was going to be changed (if it's a process that will change > >>>>> data). > >>>>> > >>>>> In your experience, what other information have you stored? Do you > >>>>> store a snapshot of the original data also? > >>>>> > >>>>> Joen > >>>>> > >>>> > >>>> > >>> > >> > > > > > |
| Free embeddable forum powered by Nabble | Forum Help |
