• 2 replies
  • Latest Post - ‏2013-05-10T19:19:44Z by OpherB
215 Posts

Pinned topic Import Metadata into FM: Dates as Indentifiers

‏2013-05-09T23:38:18Z |


Anyone know how to prevent the extremely annoying practice of FM importing dates as identifiers?  I'm nearly always changing them back.

I'm importing metadata from a transaction system (not a DW this time) and I like to only show the primary key as an identifier, so users know what the table key is.

Is it configurable?



  • vikky440
    11 Posts

    Re: Import Metadata into FM: Dates as Indentifiers



    as far my knowledge is concern you have to do it mannually




  • OpherB
    696 Posts

    Re: Import Metadata into FM: Dates as Indentifiers


    I know of nothing that allows you to change it in FM. I wonder, however, if there is something in the source system's metadata you could change that would notify FM that it's not an identifier. Might be worth investigating.

    On a former project I finally found the BEST way to make FM do what I wanted it to do: We hired an SDK developer and wrote an FM "pre-processor". It worked this way: The database was created using naming standards (all identifiers had "_ID" at the end of the column name, all measures ended with "_QTY" or "_AMT", etc.). We then pulled the raw database metadata into FM and saved the project. We then ran the pre-processor on the MODEL.XML file and it did the following:

    • Changed all _ID columns to identifiers if they weren't already
    • Changed all _AMT and _QTY columns to facts if they weren't already
    • Changed everything else to an attribute
    • Pre-pended the table name to the column name, so PO_NUM_ID in the PO_Master table became PO_Master_PO_NUM_ID as the field name in FM
    • Converted all field names to camel case after stripping the underlines out, so PO_Master_PO_NUM_ID became PoMasterPoNumId
    • There were some other clean-up items, but that was the big chunk

    This saved us about one man-month per new FM model at the cost of about three weeks of development effort for the pre-processor. It was LOVELY!

    Of course, if you have the SDK and a good programmer, you could do much more complex tasks. For example, the project I'm on now has 26 FM models and when a table has to be changed in the data source, each must have identical changes made to it. I'd like to have a program that picked up the "NEW" version and wrote it to all the others. Would be much less prone to errors than manually changing each model - as well as being much faster.

    Good luck,