Home End User
New Blog Posts: Merging Reports - Part 1 and Part 2

Data Dictionary

edited April 2003 in End User
The data dictionary seems like a nice way to present end users with user
friendly descriptions instead of obscure table and field names. However,
I see a couple of problems with this:


Firstly, the Table/Field aliases seem to be stored in the database - so
if I add a new field/table to the database structure then I have to add
additional records to rb_table, rb_field and rb_join tables in the
database - which is a bit of a pain when users upgrade from version X.Y
to X.Z of my app.

Is it possible to store the report definitions in the physical databases
but keep the data dictionary stuff in memory tables (such as TdxMemData
or TkbmMemTable)?



Secondly, the app I'm building is to be localized for French and German,
and the users choose their language when they log in (it's web based)...
so storing this information in the physical databases doesn't really
make much sense (English users can be logged in and using the same set
of databases as French and German users, all at the same time).

However, if I could keep the data dictionary aliases in memory tables
then I could localize these depending on the language that the user
selects when they log in. However, I'm wondering how this would work if
someone using English field/table aliases saves a report definition to
the databases and then someone else (logged in with french as their
language) opens the same report (since their data dictionary memory
tables would contain different aliases).

So the question, when the report definition is saved, does that
definition get saved using the actual field names, or those from the
Data Dictionary tables?

Best Regards,

James Crosswell
Software Engineer
Microforge.net Limited
http://www.microforge.net

Comments

  • edited April 2003
    You can try it, but it may be better in the long run to go with a pure
    database approach. As long as you provide the dictionary data through a
    pipeline to the data dictionary component, I don't see any problem with that
    approach for legacy users. It should work. However, we haven't built an
    example which does this, and you may not be able to use the data dictionary
    builder (as it expects a database connection), but you could populate the
    entries for the dictionary in the memory tables dynamically from a delimited
    text file you create by hand.


    Cheers,

    Jim Bennett
    Digital Metaphors


  • edited April 2003
    Cool, and for my second question: when the report definition is saved,
    does that definition get saved using the actual field names, or those
    from the Data Dictionary tables?

    A suggestion maybe - I can see why you might want to store this
    information in the databases, if you use the same end user reporting
    application to design reports for multiple applications each with a
    different database schemas. However, I think the majority of developers
    will be developing a reporting solution for a particular application
    that has a single database schema that does not change. In this second
    case, a DataDictionary component that simply stored it's Table/Field
    aliases in TCollections (i.e. in memory) would be easier to work with IMHO.

    Thanks for the tips.

    Best Regards,

    James Crosswell
    Software Engineer
    Microforge.net Limited
    http://www.microforge.net

  • edited April 2003
    Both the field name and field alias are saved down in the template. For an
    example, change the Report.Template.Format property to ftASCII and save a
    report to file with a dataview in it, then open the .rtm in Notepad. Here I
    used the Biolife table in a dataview using our AutoJoin end user demo. You
    can see that the field alias is saved using the alias that is defined in the
    data dictionary for the common name field. Try it yourself and give it a go:
    object ppField2: TppField

    FieldAlias = 'Common Name'

    FieldName = 'Common_Name'

    FieldLength = 30

    DisplayWidth = 30

    Position = 1

    TableName = 'biolife'


    Cheers,

    Jim Bennett
    Digital Metaphors


  • edited April 2003
    Jim Bennett (Digital Metaphors) wrote:

    Hmm... OK, so if I load a template and the FieldAlias does not match any
    aliases that exist in the data dictionary, will this result in an error,
    or will Report Builder be able to work it out based on the FieldName?

    I want to have different aliases for different users (depending on their
    language selection). For example, I want reports saved by someone using
    the english version of the aliases in their data dictionary to be
    readable by someone using french aliases as well... Can you see a
    problem with this, in theory?

    Best Regards,

    James Crosswell
    Software Engineer
    Microforge.net Limited
    http://www.microforge.net
  • edited April 2003
    One way to do this would be to use multiple dictionary entries into the
    database tables, but you need to add a user language field to each of the
    three data dictionary support tables to do this. You need to only return one
    data dictionary field per logical field per user language. Only the first
    entry located in the data set is usable by the data dictionary which is why
    you must filter the dataset in this case. Or you could hook up different
    database tables for each user language and switch the datasets used by the
    dictionary at runtime.

    Cheers,

    Jim Bennett
    Digital Metaphors


  • edited April 2003
    I was actually going to use memory tables for the data dictionary
    pipelines, and I'd populate these dynamically depending on the user's
    language selection, which apparently I can do. The only draw back is
    that I can't use the Wizard in the data dictionary component to add the
    table/field aliases, since this expects a database connection.

    Still, that aside, do you see any problems with FieldAliases not
    matching when I load reports that were saved using another version of
    the data dictionary?

    Best Regards,

    James Crosswell
    Software Engineer
    Microforge.net Limited
    http://www.microforge.net

This discussion has been closed.