BMC - Does Show Duplicates check box in the reports gets unchecked?

Hi Bharath,

Thanks for reaching out. We have no logged cases of such a thing happening. However, a couple things jump out at me here:

• If you're referring to our Audit Content package from the Yellowfin Marketplace when you're referring to the audit report you ran, I'd not be surprised you'd run into issues using 7.1. The Audit Content package is only officially supported in 7.4.
• On the point of Show Duplicates becoming unchecked, there's really no way of replicating this without keeping an eye on it for an extended period of time. I tried in 7.4 turning on Show Duplicate Records, saving and coming back in, but it was still checked off. 7.1 however, is out of standard support, we've not heard of this happening before, and as previously stated, Audit Content may not work properly in 7.1, so the only real option here would be to upgrade to a later version and keep an eye on it to see if this behavior still occurs.

Please let me know if you have any further questions or require any additional clarification on these points.

Regards,

Mike

Hi Mike,

Thanks for your response. We are trying to figure out how the 'Show Duplicates' was unchecked. However, no luck so far.

We have also observed some strange things happening:

- Deletion f some fields in the views.

- Some users lost permissions on the reports.

- Some fields getting deleted from the reports.

This was happening at least once a month and is very strange. So I have decided to pull some audit reports to know if any manual intervention is causing this. Finally, we had to restore the DB every time this happens.

Have you ever observed this?

Regards,

Bharath

Hi Bharath,

I've never heard of this happening before and I can't find anything similar to this in previous tickets. The most likely scenario is that these settings were manually changed or can in some way be attributed to user error or user actions. I do think that using the Audit Content package to try and determine where things may have gone awry is a good way to go about this, but as previously stated the Audit Content package isn't designed to work with 7.1, so it may not be as reliable or work as intended.

Unless there is some indication or proof these settings/fields were automatically deleted, a highly unlikely circumstance, there's not much we can do here. Further, even if we did find some sort of error that would require a code change, there are no more fixes being developed for 7.1. Ultimately, I think the next steps here are to upgrade, and if the issue still occurs, figure out where and who is making which changes.

You can reference the 'event' table in the Config DB to narrow down report results. Here you can see reports that were run and/or edited on specified dates, and in the 'EventData' column, you can see the report ID as well as the ID of who the requestor was:

Hopefully this info can help lead you in the right direction to find where and by whom changes are being made in the mean time while awaiting performing an upgrade. Please let me know if you have any further questions or concerns regarding this.

Regards,

Mike

Thanks Mike, I understand that audit content package is not officially supported for 7.1.

Does is intended to work with 7.3 version?

Also, I think this is not happening due to manual intervention. I mean when I edit a report(enable show duplicates)and run the audit report, I see that report has been edited by xxxx user.

But the activity which happened automatically, is not captured in the auditing. The previous edit date was some where in April. I understand that 7.1 is in limited support, I am just trying to figure out what would cause this.

And I dont think event table would have captured something as I dont see any thing from the audit reports.

Regards,

Bharath

Hi Bharath,

The Audit Content package isn't technically supported in 7.3, but I believe it mostly works fine. The issue here is that there's really nothing we could do to test and attempt to replicate this behavior. I've never personally seen or heard of a client having something in their environment change without being caused by user intervention.

The only possibility I can think of in terms of troubleshooting this is If you notice something has disappeared between different instances of booting up Yellowfin, if you make note of the date and time of when that setting was there and what time you noticed it missing, we can look at the logs and see if we can find something in there that indicates something dropping off.

Failing that, upgrading and seeing if this behavior persists is the only other option here.

Regards,

Mike

Hi Bharath,

I'm going to go ahead and mark this one as Answered as there's nothing I can add here aside from performing an upgrade, but if you have further questions or concerns on this, if you respond, it will re-open the case and put it back in my queue and I'll be happy to help.

Regards,

Mike

Hi Mike,

We are again having this issue. When I select 'Show Duplicates' in the report, does it store in the database?

-Bharath

Hi Bharath,

Thanks for reaching out. Show Duplicates does indeed store in the database. It's stored in the 'reportformat' table.

You can find all reports using suppress duplicates by querying:

SELECT * FROM reportformat WHERE FormatTypeCode='SUPPRESSDUPS'

If you turn off Suppress Duplicates and publish, the ReportId changes:

And if you search that new Id in the 'reportformat' table you'll see that the row with 'SUPPRESSDUPS' in the FormatTypeCode column is completely removed:

And old ReportId's are no longer found in the table at all.

The act of turning on/off suppress duplicates doesn't seem to be stored in the db, however - at least not in the 'event' or 'eventarchive' tables.

As such, it'd difficult to prove via the config db that this is not occurring due to user actions.

However, what you can do, is search for the 'RPTPUBLISH' EventCode in the 'event' table, sorting by most recent so you can see whether the report in question was recently published:

Above you can see my most recent 'RPTPUBLISH' results (my edits) that correspond with the screenshots I've attached above. From here, you can take the IpSource to link that up with the corresponding user who last published the report. This is a refresh after editing the same report with another user:

From there I can take that IpSource Id of '13008' and determine who it was in the 'person' table(IpPerson is the column in this table):

So now you can at least establish a trail of report edits/publishes and perhaps ask said user whether they perhaps turned off suppress duplicates.

Hopefully you find this information helpful! Please let me know if you have any further questions.

Regards,

Mike

Thanks Mike, I will check this out and let you know.

-Bharath

Hi Bharath,

Great. Thanks for the update.

Regards,

Mike

Hi Bharath,

I just wanted to check in and see how things are going with this.

Regards,

Mike

Hi Bharath,

I'm going to go ahead and mark this one as Answered since I haven't heard back from you, but if you have further questions or concerns on this, if you respond, it will re-open the case and put it back in my queue and I'll be happy to help.

Regards,

Mike