Is your BI solution hard to install and difficult to use?

By Tom Huntington

Is your BI solution meeting your needs? It might not be if you have any of the following symptoms: Your data is out of date; your report backlog is still a backlog; your BI technical department is larger than two people; your team spends time redefining your data to make the solution work; your technical team spends hours upon hours installing program fixes; your solution works only with one database; it's too complicated for end-users to write their own inquiries; and anytime you want to do more, you have to pay.

Enhance your DB2 Web Query reports by using drill-down capabilities.

How do your System i queries access Oracle, MySQL, SQL Server, and other databases?

Do you need to combine System i, UNIX, and Windows data all on one executive dashboard panel? Do you need to consolidate data from multiple databases in your network? Are you tired of being forced to transfer System i data from your DB2/400 database to a data warehouse so that it can be queried?

The basic i5/OS Query product allows you to access only your local DB2 data through the queries you write. IBM's new Web Query tool also allows you to access your DB2 data, but it costs extra to use and connect to other databases. In addition, you have to go somewhere else for support for these connections. Other tools allow you to access DB2 data on your System i, but they do it from Windows or UNIX. Wouldn't it be nice to have a System i-centric solution?

Use Microsoft Access as a great testing utility.

Stored procedures are great tools for easily delivering the results of one or more queries (aka result sets) to a client/server or Web application. (For a brief outline of this technique from the client side, see "Retrieve Multiple Result Sets from a Stored Procedure.") However, testing DB2 stored procedures that return multiple result sets can be challenging. For instance, I wrote a stored procedure that returns an immense amount of related data in six result sets and is subsequently processed in a SQL Server database. Every once in a while, however, there is a problem that requires examination of all the result sets for troubleshooting. How does one go about easily capturing these result sets?

Are you afraid to journal because of the potential overhead it can add to your system? Fear no more!

System i customers can receive lots of benefits from journaling their DB2 tables and files. First, journaling improves the recoverability of your databases, whether you're trying to recover from a system failure or an uncompleted business transaction. Journaling is required for any application that needs the ability to undo database changes with a rollback operation or guarantee a business transaction with a commit operation. Second, journaling provides a log of all your database changes, which can be useful to a security auditor trying to determine who changed sensitive data, such as a salary column. This log of changes can also be used by programmers when they're trying to figure out what went wrong with one of their applications.

Easily generate summary data, charts, graphs, KPIs, or graphic reports such as invoices.

BCD's Catapult is a business intelligence solution with a difference. Because it has tight integration with BCD's application modernization suite, it delivers meaningful information to users through more distribution channels than comparable products.