Data Dictionary
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
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
This discussion has been closed.
Comments
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
http://www.digital-metaphors.com
info@digital-metaphors.com
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
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
http://www.digital-metaphors.com
info@digital-metaphors.com
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
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
http://www.digital-metaphors.com
info@digital-metaphors.com
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