Hitachi Vantara Pentaho Community Forums
Results 1 to 6 of 6

Thread: Mondrian in PRD 3.6.0 GA does not like Latin Characters..Please Help

  1. #1
    Join Date
    Jan 2007
    Posts
    485

    Default Mondrian in PRD 3.6.0 GA does not like Latin Characters..Please Help

    Hi All,

    I have been building reports that use Pentaho Analysis - OLAP queries. Everything is fine just as long as no "latin-characters" (é, ñ... and the like) are involved.

    I am using PRD 3.6.0-GA.11125 and BI Server CE 3.6.0.stable.41852, on Windows.

    When using the BI Server, my *.mondrian.xml and *.xaction files, I am setting the encoding to use "ISO-8859-1". Is there any means by which one can do the same in PRD and or in the "Mondrian" query reader which I imagine is within PRD?

    Many thanks...

  2. #2
    Join Date
    Mar 2003
    Posts
    8,085

    Default

    First thing: Check whether the code works fine in JPivot or Analyzer. If it does, you have a reporting problem and we can talk.

    If it does not, then you have a problem with your cube or with your databases.

    In case you have a reporting problem, you most definitely have a encoding problem, and you should only see that kind of trouble in PDF reports. All other reports put no font-based constraints on what characters can be displayed. For PDF, make sure your elements DO NOT USE A BUILT IN FONT. Anything that reads "Serif", "SansSerif", "Dialog" or "Monospaced" is evil. We map these built-in Java fonts into their equivalent PDF counter parts. PDF defines that PDF built in fonts are only valid for Western-European charsets.
    Get the latest news and tips and tricks for Pentaho Reporting at the Pentaho Reporting Blog.

  3. #3
    Join Date
    Jan 2007
    Posts
    485

    Default

    Thank you Tomas...

    I confirm my MDX works perfectly in JPivot and SchemaWorkbench (PSW); not son in PRD, so the problem is in the report.

    The error (in one of the cases) plainly says "...the Ñ character is not accepatble...", regardless of whether output is HTML, PDF, Excel, etc. Besides the latin char problem, I did have to tweak the MDX to get the original-fully functional under JPivot/PSW- to get it to be recognized by PRD. (ie. one of my dimension.members -besides the latin chars- has spaces, and while these are perfectly recognized in JPivot, that was not happening in PRD.

    Not as knowlegable as you in PRD, and not to discard a potencial encoding problem.... I having to tweak the MDX select leads me to suspect would be in the "mondrian" component that is incorporated into PRD...??

    Let me know what can be done to resolve this.

    Again, many thanks for your interest and reply.

    Kind regards, DMurray3

  4. #4
    Join Date
    Mar 2003
    Posts
    8,085

    Default

    Well, we use the same JAR as in the BI-Server. I would suspect that you have to tweak the mondrian-configuration in PRD to make it work. Something in that error message sounds as if the MDX parser does not like the query or value.

    Do you have a stacktrace?
    Get the latest news and tips and tricks for Pentaho Reporting at the Pentaho Reporting Blog.

  5. #5
    Join Date
    Jan 2007
    Posts
    485

    Default Mondrian in PRD 3.6.0 GA does not like Latin Characters..Please Help - Stack Traces

    Hi Tomas... Sorry for delay in getting back on the reported problem.

    Enclosed, please find the schema I am using, as well as images of the MDX statements that work correctly in JPivot, which are the same that when used in PRD 360, are not being recognized.

    In the enclosed files:
    - ImageWorkingJPivotMDX1.jpg generated the error in ReportErrorStackTrace1 in PRD 360;
    - ImageWorkingJPivotMDXQuery2.jpg generates the ReportErrorStackTrace2 in PRD 360.
    - I am also including the .prpt and my schema, should you requiere these.
    - Another issue I have is when passing a "string" param (like ${my param string} in the MDX) which contains spaces, causes the MDX to fail.

    Any help you can provide will be highly appreciated.

    Kind reagrds, DMurray3
    Attached Files Attached Files

  6. #6
    Join Date
    Mar 2003
    Posts
    8,085

    Default

    ReportErrorStacktrace2:

    This is caused by you not quoting the parameter correctly.

    The Rank function does not quote the member in square brackets, and that makes mondrian interpret the value as function name. Function names are defined to be ASCII only, no other characters are allowed.
    'Rank([Entidades].[BCOS].${subparamCodEntidad},
    will resolve into

    'Rank([Entidades].[BCOS].somevalue,
    which probably is not what you want.
    You want it to resolve into

    'Rank([Entidades].[BCOS].[somevalue],
    instead, dont you?


    A ${..} parameter is a string replacement operation. Therefore anything you pass in must result in valid MDX. If you pass in some space in a place where space is not allowed according to the MDX syntax, mondrian will complain.



    Stacktrace 1: Your member is not fully qualified. Apparently Mondrian found more than one possibility and was not able to decide which function to use. Actually, if I remember right, in PRD-3.6.1 and later I actually changed the Mondrian config to *forbid* unqualified members. With unqualified members, you could specify "[key]" as member and hope that mondrian resolves it right. But mondrian's parsing of members is stateless, it happily returns the *first* member it encounters and does not take into account whether the reference was declared on a Axis where such a member would not be allowed.

    To fix it, either fix your query or copy your BI-Server's mondrian configuration (mondrian.properties) to PRD, so that both use the same config.
    Get the latest news and tips and tricks for Pentaho Reporting at the Pentaho Reporting Blog.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.