Monday, October 5, 2015

One of the features of Dodeca is read-write functionality to SQL databases. We often get questions as to how to write data back to a relational database, so I thought I would post a quick blog entry for our customers to reference.

This example will use a simple table structure in SQL Server though the concepts are the same when using Oracle, DB2, and most other relational databases. The example will use a simple Dodeca connection to a JDBC database. Here is the Dodeca SQL Connection object used for the connection.

The table I will use for this example was created with the following CREATE TABLE statement.

First, I used the Dodeca SQL Excel View Wizard to create a simple view in Dodeca to retrieve the data into a spreadsheet. The view, before setting up writeback capabilities, looks like this.

To make this view writeable, follow these steps.

Add the appropriate SQL insert, update, or delete statements to the Dodeca SQL Passthrough Dataset object. The values to be replaced in the SQL statement must be specified using the notation @ColumnName where ColumnName is the column name, or column alias, of the column containing the data.

Add the column names of the primary key for the table to the PrimaryKey property of the SQL Passthrough DataSet object.

Depending on the database used, define the column names and their respective JDBC datatypes in the Columns property of the SQL Passthrough Dataset. This mapping is optional for SQL Server because Dodeca can obtain the required information from the Microsoft JDBC driver, however, the Oracle and DB2 JDBC drivers do not provide this information and it must be entered by the developer.

For insert, update, and delete operations, Dodeca parses the SQL statement to read the parameters that use the @ indicator and creates a JDBC prepared statement to execute the statements. The prepared statement format is very efficient as it compiles the SQL statement once and then executes it multiple times. Each inserted row is also passed to the server during the transaction. The values from each row are then used in conjunction with the prepared statement to perform the operation.

Here is the completed Query definition.

Next, modify the DataSetRanges property of the Dodeca View object and, to enable insert operations, set the AllowAddRow property to True. Note that if you added update and/or delete SQL to your SQL Passthrough Dataset object, be sure to enable those operations on the worksheet via the AllowDeleteRow and AllowModifyRow properties.

Once this step is complete, you can run the Dodeca View, add a row, and press the Save button to save the record to the relational database.

The insert, update, and delete functionalities using plain SQL statements is limited to operations on a single table. If you need to do updates on multiple tables, you must use stored procedures to accomplish the functionality. You can call a stored procedure in Dodeca using syntax similar to the following example:

Sunday, June 14, 2015

We recently released an updated version of the Next Generation Outline Extractor. This new version, 2.0.4.887, addresses three issues:

Fixed an issue where the username and password passed via the command line were improperly logged

Fixed an issue reading MaxL XML data sources when the alias or UDA contained xml encoded characters such as the ampersand (&) character.

Updated labels on the Input Source tab of the user interface to clarify their purpose.

Here is a screenshot showing the updated labeling.

Due to the architecture of the Oracle Essbase APIs, it is generally much faster to use the MaxL Outline XML extracts when processing an Essbase Outline extract. The Next Generation Outline Extractor still uses the Essbase Java API during this extract, but it is able to minimize the number of calls. The second option shown above, Extract and Process MaxL Outline XML, will automatically extract the Outline XML from the cube during the processing. The third option shown, Use Previously Extracted MaxL Outline XML, uses (obviously) an Outline XML file that has already been extracted.

Thank you to everyone who reported issues or made suggestions as you help make this utility better!

Friday, May 8, 2015

Have you ever wanted your users to see an Essbase database outline structure, but had trouble giving them access to Essbase Administrative Services ("EAS") for fear that they may have access to change things they shouldn't change? Maybe you didn't want to give them EAS and have to deal with the version of Java installed on their machine? We have the solution to your problems. After a bit of fits and starts, we have finally released the OlapUnderground Essbase Outline Viewer!

The OlapUnderground Essbase Outline Viewer is a read-only user interface built specifically to view the contents of an Essbase outline. It is built in Microsoft .NET technology and should run on any Windows-based computer without any special downloads. It also uses the MaxL outline xml format and, as your Hyperion administrators can create and distribute the outline xml file, end users do not need an Essbase login to view the outline.

2015.02.13 - Issue 1351 - Fixed issue with LoadFileWriter where UDA column headers were incorrectly written in the form UDAS0,DimName instead of UDA0,DimName

In addition, a number of fixes, etc, were put into 2.0.2 and earlier releases and those releases went unannounced. Those updates included the following items:

There is no longer a default .properties file for the Extractor. This will force a user to specify a .properties file. (2.0.2.601)

Removed the "/" character as a switch for command line arguments as it causes problems in Linux. (2.0.2.605)

Fixed issue when combining MaxL input with relational output where a "not supported" error message would appear due to certain properties were not being read correctly from the XML file (2.0.2.601)

Command line operations resulted in an error due to an improper attempt to interact with the GUI progress bar. (2.0.2.601)

Shared members attributes where not be properly written resulting in a delimiter/column count mismatch. (2.0.2.625)

Added encoding options where a user can choose between UTF-8 and ANSI encodings. The Extractor will attempt to detect encoding from selected outline and, if the detected outline encoding is different from the user selected outline encoding, a warning message appears.

Friday, February 13, 2015

The issue that has plagued a number of Essbase customers over the years related to running out of available ports has finally been fixed!

This issue, which often manifested itself with errors in the Essbase error 10420xx range, was caused by how the Essbase Java API communicated with the server. In essence, whenever a piece of information was needed, the Essbase Java API grabbed a port from the pool of available ports, did its business, and then released the port back to the pool. That doesn’t sound bad, but the problem occurs due to how Windows handles this pool of ports. Windows will put the port into a timeout status for a period of time before it makes the port available for reuse and the default timeout in Windows is 4 minutes! Further, the size of the available pool of ports is only about 16,000 ports in the later versions of Windows. That may sound like a lot of ports, but the speed of modern computers makes it possible, and even likely, that certain operations, such as the outline APIs, that call Essbase many, many times to get information would be subject to this issue. Frankly, we see this issue quite often with both VB and the Java Essbase Outline Extractors.

We brought this issue to the attention of the Java API team and assisted them by testing a prerelease version of the Java API jars. I am happy to report the fix was released with Essbase 11.1.2.3.502. In addition, there is a new essbase.properties setting that allows you to turn the optimization on or off:

olap.system.socketoptimization=false

It is our understanding that this optimization is turned on by default. I also checked the default essbase.properties files shipped with both Essbase 11.1.2.3.502 and 11.1.2.4 and did not see that setting in those files. It may be one of those settings that is there in case it messes something else up. The work of our own Jay Zuercher in our labs and searching Oracle Support seems to have confirmed that thought. There is apparently an issue where EIS drill-through reports don't work in Smart View if socket optimization is turned on. It is documented in Oracle Support Doc ID 1959533.1.

There is also another undocumented essbase.properties setting:

olap.server.socketIdleTime

According to Oracle development, this value defaults to 300 ms but there should be little need to ever change it. The only reason it is there is to tune socket optimization in case more than 2 sockets are used per Java API session.

Jay also tested the 11.1.2.4 version in our labs with the Next Generation Outline Extractor. With the default settings, one large test outline we have, "BigBad", with about 120,000 members in it, extracted in 1 minute and 50 seconds. With socket optimization turned off, the same outline was only about 25% complete after 2 hours. In summary, this fix will be very useful for a lot of Oracle customers.

Thursday, February 12, 2015

It is with a sad heart that bring you the news that, as of Essbase 11.1.2.4, the Essbase VB API is officially dead. I cut my teeth in Essbase working with that API way back in the mid-1990's, but the writing had been on the wall for some time. Microsoft stopped supporting VB years ago, so it was only a matter of time before this time would come. That being said, I haven't used the VB API for any new Essbase work since about 2001; the Essbase Java API is alive and growing so my efforts have been there.

About Me

Despite the fact that I often work half-days (12 hours), I am one of the luckiest geeks in the world. I am married to the perfect wife as she is smart, beautiful and provides a tremendous amount of support that makes it possible for me to do all of the things that I do.