Hi,
I’m using XIr2SP4 and have got to the Auditing stage of the project!
Has anyone got any comments on doing an integrity check on the Acivity Universe.
I have got 5 parse errors and 10 cardinality divergences from BO out of the box on this universe. Is this normal 
Darth Services 
(BOB member since 2007-11-20)
So, just me then?! 
Darth Services 
(BOB member since 2007-11-20)
Not really 
As far as I remember I had to fix some issues in the Activity Universe for an Oracle database. Some joins were wrong and I think also some objects had wrong definitions, they did not parse.
So you are not the only one 
Marek Chladny 
(BOB member since 2003-11-27)
I’m having ‘5 parse errors and 10 cardinality divergences’ too…
nicoleflopy 
(BOB member since 2009-10-23)
That’s quite normal
Marek Chladny (BOB member since 2003-11-27)
I have now upgraded to BOXI 3.1 and there are still issues when performing an integrity check on this universe out of the box!
Structure: 2 divergences (one of which says the AUDIT_EVENT table has changed)
Parse Objects: 3 Errors
Check Cardinalities : 27 divergences
All the others are OK though…
Darth Services (BOB member since 2007-11-20)
Hi,
Interesting.
If you fixed the issues, you could write here what you did so others could benefit from it.
Thanks.
Marek Chladny 
(BOB member since 2003-11-27)
Does this mean the Activity Universe was designed for MySQL out of the box? Is that why we are seeing errors when changing the audit database and CMS database to Oracle? What’s the best way to update Activity to Oracle?
gjwl_8 (BOB member since 2010-02-17)
Hello Marek Chladny,
Can you please tell us what did you use as a ER diagram while fixing Join issues. Our auditor database is in Oracle 10G, even we are having some join issues. Any help will be very much apprecaited.
sanappi (BOB member since 2010-05-03)
Hmm, if only I remembered, it was several years ago.
I remember that some joins used columns that did not match; some joins were missing, some objects did not parse because of wrong definitions, etc. I used common sense and fixed the bugs. But can’t tell you details now.
Marek Chladny (BOB member since 2003-11-27)
thanks Marek for your reply. But can you look at the attached screen shot and suggest me what to do to resolve. Will be very helpful.
sanappi (BOB member since 2010-05-03)
Attached? Where?
Marek Chladny (BOB member since 2003-11-27)
sorry looks like it didnot go through last time. I am trying to attach it here.
sanappi (BOB member since 2010-05-03)
I attended an online course on universe best practice run by Matthew Shaw from BO UK - he is very knowledgeable on good practice and advocates a technique wherby you arrange tables in Designer from left to right in the direction of the 1-to-many relationships. When you do this you tend to find that your fact table ends up on the right hand end. This allows you then to visualise the so-called fan and chasm traps quite easily. For example in this case the audit event table feeds in to the audit detail table as a fan. In such situations you cannot place sum measures on the left hand part of the fan and you can only place count measures if used with distinct. In the universe as supplied the count is NOT distinct and hence we get these errors. I think this is quite poor for a part of the distribution. Count distinct should correct this, but I am unhappy to have my own version of the universe. I believe they should supply a correct one.
I am also not sure about the derived tables that they have created as these appear to imply a chasm trap. There are no contexts used in the Activity universe, so if objects are used from sevaerl of those derived tables, then, without the use of count distinct, they will result in duplicate rows.
UPDATE
Have now gone on to notice that they have not been consistent with the joins to the derived tables. In each of these tables there is a join to the event table on both event id and server cuid. When this is done as a complex join, it gets correctly detected as 1 to many join (event to derived table). Where it is done as two separate joins, then the cardinality of the server cuid join is many to many and this seems to suppress the automated context detection. Once you change these all to 1 to many complex joins, then the context detection springs in to life.
twofivepie (BOB member since 2008-10-16)