I wrote1 a few days ago: I would also like to define metadata for the database. For example, if a
report uses the field 'name' from the table 'customers' then automatically
that field should have the title 'customer name' (in Hebrew) Similarly,
'surname' and 'forename' from table 'people' or 'name' from table
'therapists'. The fact that I want the title in Hebrew is incidental; even
in English, the default name for customers.name is 'name', not 'customer
name'. I put this to CoPilot who replied that this would be very easy to do: it
requires a dictionary that translates between table names and Hebrew titles,
and that the source for the dictionary would be a property of each field
called 'origin'. The origin propery of a field containing a customer name
would be CUSTOMERS.NAME.
I left this idea for a few days while I concentrated on list boxes, but yesterday
I returned to continue work on this idea. I linked the 'find dictionary entry' procedure to a
simple report and saw ... that it didn't work. The origin of a field
CUSTOMERS.NAME was simply NAME and of course I have to distinguish between
customer name, therapist name and activities.name, etc. CoPilot said that
the table name didn't appear because the query was very simple and didn't
invoke a join. So I looked at a more complicated query and saw that the
origin property was empty for half of the fields! Only fields from the base
table (ie the table after the keyword FROM) had origins, whereas the rest
didn't.
OK, said CoPilot, you need the OriginTabName and OriginColName
properties. "These do exist and will compile." Except they don't exist.
After several rounds of CoPilot offering names of properties that sound
plausible but don't exist, I told CoPilot that we were getting nowhere. CP
agreed, saying that FireDAC doesn't expose sufficient metadata in order to
provide a solution for what I wanted. Thank you very much. It wouldn't hurt to say once in a while that "I got it wrong".
In the end, I suggested and implemented a much simpler - and unfortunately,
less automatic - solution: I created a stringlist and populated it with the
Hebrew translations of 'customer name', 'contact name', 'person surname',
etc. Each value has a specific number attached to it which is simply the
offset within the stringlist: stringlist[1] = 'customer name', etc. In the
FDQueries and FDMemTables in my code, I assign one of these values to a
field's tag propery and then do the lookup on this property. In the
extremely complicated form for sending an email, upon which I worked, at one
stage it is necessary to display a list of therapists. Instead of having to
title each field manually, I simply marked the tags as 56 and 58 and got the
displaylabels that I wanted.
In conclusion: there are some things that CoPilot is good at, like seeing
that a datasource was not
enabled2, or for building an
ancestral dual list box dialog3. But for more creative solutions, CP is not particularly good
and is even frequently wrong. And it still maintains that "This is reliable,
simple, and works with all your existing forms". Yeah, right (the one time
that two positives make a negative).
I've been so wrapped up in all this chat coding for the last few days that
I didn't notice that this is blog #2100! The next blog will contain the
traditional look at the previous 100 blogs.
Internal links
[1] 2097
[2] 2094
[3] 2099
This day in blog history:
| Title | Tags | ||
|---|---|---|---|
| 1384 | You and your action research project | DBA | |
| 1918 | Is this me or a double? | Personal |
