Field name confusions
Many many years ago I wrote my own dictionary data generation interface that
concatenated the table name with the field name so that when trying to find
field in the Data Tree it was easy to identify what was what, particularly
when joining 5 tables all with common field names like IDX or Description or
Name. Yesterday, I had to write some reports that were to be stored as file
templates only, without all the RB tables, and I soon found out how much I
missed my custom dictionary implementation.
Finding fields is painful, especially when you have lots of them and some
dick brain who wrote the database schema didn't think through field naming
very well. Each time I wanted to add a field to the report designer I had to
go to the Query Designer to rename its field alias...it was awfully slow and
boring. I've been one of RB's biggests fan for years, but this bit of the UI
is a bit primative. Either the fields should be auto aliased with the table
name prefix (or there be a Wizard for doing so)or the Data Tree should
identify the data source for the field. Or have I just embarrassed myself
because the is a really obvious way of working this out that I've overlooked
for 7 years ?
Paul
concatenated the table name with the field name so that when trying to find
field in the Data Tree it was easy to identify what was what, particularly
when joining 5 tables all with common field names like IDX or Description or
Name. Yesterday, I had to write some reports that were to be stored as file
templates only, without all the RB tables, and I soon found out how much I
missed my custom dictionary implementation.
Finding fields is painful, especially when you have lots of them and some
dick brain who wrote the database schema didn't think through field naming
very well. Each time I wanted to add a field to the report designer I had to
go to the Query Designer to rename its field alias...it was awfully slow and
boring. I've been one of RB's biggests fan for years, but this bit of the UI
is a bit primative. Either the fields should be auto aliased with the table
name prefix (or there be a Wizard for doing so)or the Data Tree should
identify the data source for the field. Or have I just embarrassed myself
because the is a really obvious way of working this out that I've overlooked
for 7 years ?
Paul
This discussion has been closed.
Comments
have the custom generation code, I would try creating a custom
DataDictionaryBuilder by copying the source code to the existing one.
Perhaps we should add an option to the DataDictionaryBuilder to
automatically add the tablename.fieldname as the default Alias? Would that
satisfy your requirements?
We use feedback to drive what gets added to future versions. Have had little
to no feedback about implementing a custom naming scheme. I think that is
because customers have many different types of database designs and systems
they are designing. What is desirable to one customer, is annoying to
another. I imagine some customers manually enter/modify the DataDictionary
entries and other customers write their own DataDictionaryBuilders.
--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
I've been using my own custom DataDictionaryBuilder for years to get around
this problem, but yes, I guess it would make sense for you to add this
facility to the standard one (its only a few lines of code). But that wasn't
my real point: if its not appropriate to use a data dictionary, then in a
DADE environment, with a hundred or so fields in the DataTree, I fail to see
how a human can easily understand what is what, without knowing what the
underlying data source (table) for the field is. Its possibly the one thing
that Crystal Reports (I hang my head in shame...I'm still obliged to have
dealing with it) does nicely.
Other than this one whinge, I still marvel at how much control RD gives me
over report generation. Its the best by far
Paul