locked
Metadata nightmare RRS feed

  • Question

  • We have been having an issue similar to this post: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2445488&SiteID=17

     

    It seems that when a cube is updated and member names change or are added/removed, ProClarity tries to fix this using the Missing Data wizard.  However, sometimes the behavior of the wizard seems inconsistent- like saying there is no missing data, but then when you open another view, it pops up showing data missing.  Other behavior is when it corrects the missing data, but doesn't allow the page to render, causing other errors (see link above).  Sometimes, it allows you to fix a page, and view it, but when you return to the page again, it prompts you to fix it again.

     

    I came to the conclusion that it may be due to the MDStore information that ProClarity stores in it's briefing book.  I've exported our book as XML and inspected this file, and noticed some interesting things:

     

    1. It contains references to cubes/databases that no longer exist on the server (note that all pages that referenced these databases/cubes had also been removed or changed to reference the new cubes/databases)
    2. Using the "Change connection wizard", it appears to be case sensitive.  When I impropertly changed the case of a database name (i.e. MySSASDb as MySSASDB), it created a new element in the XML and duplicated all the metadata- and if I needed to run the missing data wizard, it only changed one of these elements metadata.  This seemed to cause an endless loop that fixes, then breaks again because it gets confused.

    So, my assertion is this behavior isn't what is expected.  If no pages reference database and cubes, the metadata should be removed from the briefing books.  The MDStore object contains only a single reference to a server, so it makes little sense why it couldn't determine that objects on that server do not exist anymore, and remove the entire fragment of metadata.

     

    The next is to use the object ID on the server for the database and cube, and not rely on the name itself.  This way it won't duplicate any metadata and get itself confused when fixing/updating pages.

     

    According to the link referenced above, if these types of problems exist, there isn't an easy way to resolve this, and may require manually creating the books again.  This seems unacceptable in my opinion.  Has anyone created any automation to assist with this so we don't have spend days redoing our reports??

     

    Saturday, February 16, 2008 6:13 PM

Answers

  • This certainly does sound a bit like a nightmare.

     

    Your suggestions for improvements are good ones, and I agree the MDStore/Missing Data Wizard feature could be enhanced.  However, I think we'll have to look for these improvements in PerformancePoint Server, as the ProClarity product line is not currently under active development, with only support for SQL Server 2008 scheduled as a feature addition at this time.

     

    There are a couple of things you might test in your current situation.

     

    1.  Be sure that after you repair a view with the Missing Data Wizard that you then take the extra step to save the repaired view back to the book, as the view with the missing data is still saved in there until that extra step is taken.

     

    2.  In the Pro client, in the Manage Books dialogue, if you create a new book and copy these pages into the new book you should get a new MDStore.  Some have found this helpful in recovering their views.

     

    Regarding a utility to make batch changes to the MDStore, I am not aware of one.  I know there have been attempts at this in the past, but the APIs don't lend themselves to this effort, and modifying the XML directly has been thought to be overly complicated.  However, if copying the pages to a new book solves some or all of the issues, creating a utility to do that would be much more straightforward.

     

    Wednesday, February 20, 2008 1:35 AM

All replies

  • A few other interesting finds:

     

    The Catalog/Cube/Database names in the MDStores.xml file are ignored.  You can change this to anything and it will still read the main book file without errors.

     

    The MDX in the report page isn't accurate or up-to-date.  I exported the book as XML, and inspected the MDX comared to what I can view within ProClarity Desktop client for the same report.  The MDX was completely different- even pointed at two different cubes.

     

    You can delete the MDStoresLink node from the book.xml file, and it won't use the MDStore file to validate itself.  Although, this may cause reports not to function afterwards.

     

    The Clients node in the MDStores file seems to link to each individual report page in the book.  The documentation says Client means User.  This doesn't make sense, as the MDID for each node points directly to a specific page in the briefing book, not to any user (unless they consider a report = user).

    Monday, February 18, 2008 7:37 PM
  • This certainly does sound a bit like a nightmare.

     

    Your suggestions for improvements are good ones, and I agree the MDStore/Missing Data Wizard feature could be enhanced.  However, I think we'll have to look for these improvements in PerformancePoint Server, as the ProClarity product line is not currently under active development, with only support for SQL Server 2008 scheduled as a feature addition at this time.

     

    There are a couple of things you might test in your current situation.

     

    1.  Be sure that after you repair a view with the Missing Data Wizard that you then take the extra step to save the repaired view back to the book, as the view with the missing data is still saved in there until that extra step is taken.

     

    2.  In the Pro client, in the Manage Books dialogue, if you create a new book and copy these pages into the new book you should get a new MDStore.  Some have found this helpful in recovering their views.

     

    Regarding a utility to make batch changes to the MDStore, I am not aware of one.  I know there have been attempts at this in the past, but the APIs don't lend themselves to this effort, and modifying the XML directly has been thought to be overly complicated.  However, if copying the pages to a new book solves some or all of the issues, creating a utility to do that would be much more straightforward.

     

    Wednesday, February 20, 2008 1:35 AM