Have you ever noticed times when the error messages you receive in EAS just don’t seem to make sense?  Sometimes the Oracle Essbase Administration Services (EAS) console throws an error, but does not present additional context in the error message that will help you identify the issue.  Well, I have just run across another one that had me perplexed.

The issue that I came across was regarding an error while loading data via a flat file. When developing the data load rule, everything was looking great. I could open the Data File in EAS, build the load rule and have it validate.

Data file view in Oracle EAS

I was happy and ready to move on with my application development.  Of course I should have known that things never go as planned while in development.

The problem presented itself when I tried to load the data into the Planning application. I received the following error.

Essbase errors - load syntax error

Syntax error near(‘s’)” ???  What in the world did that error mean? This was a very straightforward flat file load rule, with no transformations or modifications done within the load rule definition.  I was scratching my head to understand this one. I looked at the EAS Application Log files for the error and there was no reference to the error.

I went through the usual suspects – Is there an issue with the data in the file? Did the Load rule get corrupted?  I recreated the rule and revalidated the file, yet the error persisted when trying to load the file again.  I could not for the life of me figure this out. Then one of my colleagues suggested that I look at the file directory where it was stored.

Low and behold there was the issue!  One little punctuation mark.   I had used an apostrophe in the directory where I had stored the flat file.

C: \Documents\Client‘s Data\Data.txt

Essbase Load rules do not recognize the apostrophe when reading the file path.  It is an illegal character.

Moral of the story – stay away using different punctuation when naming files and directories!   And when encountering an error, always look one step beyond the immediate scope of the problem area.

 

Questions?  Comments?   Feel free to reach us at:

Jon Harvey, jharvey@ecapitaladvisors.com

Jim Frederick, jfrederick@ecapitaladvisors.com