Our WebI Administrator finally turned on auditing for us yesterday and worked with our DBA to create the 6 audit tables. She is scheduled to shut the sever down and restart it tonight to begin the loggin process.
Well, being the curious person I am, I decided to take a look at the 6 tables…and the OBJ_A_EVENT_LOG and OBJ_A_SITE_LOG table are alreayd populated with approximately approx 30K and 20K records each…with dates going back from Oct, 2002 to present.
Does this indicate that auditing was previously turned off and had been spooled to file? If so, does this mean we may run into the problem I’ve seen discussed here before about getting duplicate events ?
I’m wondering whether we should delete the data from these log tables. In a way, I’d like to keep them because it means I have a good chunk of data to play around with as far as reporting goes.
P.S. Regarding this download that contains an updated version of the Audit universe (Report on WEBI audit information)…why are the reports included in this zip file? They are developed against the old version of the audit universe that BO supplies.
Are there updated versions of these reports available somewhere else?
I’d delete it rather than run the risk of having messed up data. If you’ve done a reinstall since then, you’ll definitely have issues. You can copy the data off into another schema/database if you want to play around with it for reporting but if you ever get messed up ids, you’re stuck deleting all the data. It isn’t worth the risk.
sounds like you have some reports with VBA macros included in them.
As far as you audit tables, you will want some form of archiving as the row count can get HUGE quickly. We are rolling off past 60 days every week; there is supposed to be a process to recall history if needed but has never been done. Really, when I covered this part of things, I was only concerned about the last day or week and published summary reports for the last month.
No, I don’t think that’s it. I just checked the event log for all “Execute macro (VB)” events and noticed that the sessions for each of the rows returned starts with “BCA_1bo1…”
It appears that BCA invokes some VBA macros behind the scenes. I never know that about the product. I wonder if anyone else can confirm.
Yes, it does. 8) Under an older version, you could actually capture the code as it was written on the fly and stored in a temp directory. You could then use that code as a starting point for something that you wanted to write.
But AFAIK BCA does use “temporary” macros to process the document(s).
I’ll second that. We were having problems distributing documents refreshed with profile until I granted the receipients ‘Import/Convert Scripts’ and ‘Run Scripts/VBA Code’ permission in the ‘Reporter/Programmability’ list. Here is a reference to it.
I’ll add yet another confirmation. If you have a VBA project “locked” (password protected), that document will fail when run via BCA. BCA can’t insert the needed VBA in a locked project.
(BOB member since 2003-11-15)