Greetings.
I'm on the middle of doing a log of changes to a record (for auditing purposes) and wonder wich would be the best / right way to do it.
I came to this idea: (this would be a table to store all changes to all records of interest)
Id -> fk to the record being changed (following advices taken form past posts here, now records have an uuid as internal id)
date - of change
user - that made the change
before
after
on the before and after fields I would store corresponding json serialisation of the record at hand (WRITE-JSON).
Wonder if it is a good way of doing it, or otherwise is there some technique/method that best suits this task?
Any experience sharing on this matter would be very appreciated
Thanks
the progress database has great builtin auditing features to do just that. that's the first place i would look at.
in regards to a generic way to save records have a look at the raw-transfer statement.
Thanks Alon...
I'll check auditing options on db, as you told.
on the other side, I'm thinking the process of storing the "before image" and "after image" of the poor man I inteded to use, would allow this only table to store any kind of recorded image, whether it would be a customer or it may be an order record . There only would be the need to do some kind of magic to show the record, no matter the table of origin..
It could be nicely integrated to application
What you think?
Input??... anyone?
To be honest with you, you're unlikely to get more input than you already have. OE Auditing is what you need, so why bother reinventing the wheel. It's hugely flexible allowing you to audit at a field level, so more granular than table auditing, and all the info on old and new values is fully available. It's simple to implement, and once you have an archive strategy in place is very easy to maintain.
Do not screw around trying to create your own solution. Use OE Auditing.
By the way -- it does not cost anything extra. It is a base capability of the database. It is not an add-on license.
It is accesible to user? It's a fiancial system.. Don't want to invest time on getting the reports they need some time to time...
Thanks.
You'll need to do some programming to access the auditing data. One shortcoming of Auditing is it does not track which program the event took place in - the engineers looked into what it would take to implement that and concluded it was too difficult to implement.
you are about to increase the load on your database threefold and its size by many gigabytes.
i suspect you do not need to record everything. you do not need after data at all. if eaqch audit record has before data, then you have it all, ending with the current record in the table.
you should review why you are doing this and what it will be used for.
the less data you record in your audit table, the better. anything you are not certain you need it, dont record.
gus
> On Nov 8, 2015, at 5:31 PM, OctavioOlguin wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> OctavioOlguin [https://community.progress.com/members/octavioolguin]
>
> Thanks Alon...
>
> I'll check auditing options on db, as you told.
>
> on the other side, I'm thinking the process of storing the "before image" and "after image" of the poor man I inteded to use, would allow this only table to store any kind of recorded image, whether it would be a customer or it may be an order record . There only would be the need to do some kind of magic to show the record, no matter the table of origin..
>
> It could be nicely integrated to application
>
> What you think?
>
> View online [https://community.progress.com/community_groups/openedge_development/f/19/p/21255/74641#74641]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_development/f/19/t/21255/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_development/f/19/p/21255/74641?AbuseContentId=c72c345a-59d0-4602-aeac-ef8b7d6f6d96&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.
We have an old system that has it's own poor man's auditing and it works fine, but it /does/ impact performance and database storage (> 80% of our db is in the auditing tables). We have been looking into the real thing but since the current way of working 'just works' there is no urgency to replace it with the built in auditing mechanism of OE itself.
I think that kind of makes sense. But if we didn't have this system in place allready, I would not advise to have it built by our own team. Why invent a wheel when you already have one? Why risk creating security loopholes, performance pitfalls, man-hour drains and bug solving if you can prevent it?
Just go with the flow, forget building it yourself, unless you have a very good reason to do so and use Auditing