Tag: xml

10

Export all report XMLs to file system – Updated

| cognospaul

2 years ago, I posted a method for exporting all of the reports to the file system, using the same folder path. I was never happy with that method, as it required adding a UDF to the content store, and large reports would fail. Since getting these reports was a requirement at one of my clients, I finally had the time to tweak it.

Unlike the previous version, I don’t have access to Oracle, so this is on SQL server. The connection string to the server is handled from inside the script (row 151), all you need to do is change the data source and catalog details to connect.

The reports will be saved under c:\temp\reports. You may want to change that as well (row 244), but don’t forget that windows has an absolute limit in the number of characters in a file path.

Unlike the old version, this will also pull reports from users’ My Folders, including orphaned reports from deleted users. The user reports will be saved under \users\<user name>\my folders\. This will also generate a log file including the sql query sent to the db, and all of the reports generated.

Due to security concerns, the file has been renamed to getreports.vbs.txt. Simply rename that to getreports.vbs to enable it.

I tested this on Cognos 10.2, on SQL Server 2005. If anyone has access to Oracle and wants to adapt the SQL, I’ll  gladly amend the post to include it.

 

getreports.vbs (1611 downloads)
Uncategorized

BmtActionsHelper.cpp(500) crash when trying to delete an object in Framework

| cognospaul

Ever since the upgrade to 10.1.1, many developers have been reporting an issue with Framework Manager. At some point during the development, Framework suddenly starts crashing whenever they delete or move specific items from the model. Frustratingly, trying to fix the issue by importing the model into a new model tends to copy the same problem.

The error in question is as follows:

Invariably, the developers would be frothing at the mouths because either they forgot to save their changes when it crashed, or they have saved their changes, and now they don’t have a way to revert back to before it started crashing like this.

The manifestation of the bug tends to follow a similar pattern. The models are generally complex, old, and contain more than one package. Some models that exhibit this bug have security, and some don’t. Deleting some fields trigger the bug, and some fields don’t. However, because the crash only happens with specific data items, it makes it easier to track down where the problem is.

In this case, a simple verify model explains what the issue is:

A glance at the model.xml shows that, somehow, there are two security views with the same name.

The easiest way to fix the problem is to delete one of the duplicated securityView nodes. There is a risk that Framework will continue to crash if the remaining securityView contains references to deleted objects, so at the very worst you can paste in:

<securityView><name>GO Sales (query)</name><definition/><access/><functionSets/></securityView></securityViews>

If this happens, you will have to redefine the package definitions, but at least the model will be viable again.

EDIT: Lose your work after the crash? See here on how to recover everything!