Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
Field name alias |
Fri, Jun 24 2016 5:39 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it?
I'm building a skills / competencies matrix system and everyone seems to use different terms for each level. Roy Lambert |
Sun, Jun 26 2016 5:55 PM | Permanent Link |
Jeff Cook Aspect Systems Ltd | On 24/06/2016 9:39 p.m., Roy Lambert wrote:
> Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it? > > I'm building a skills / competencies matrix system and everyone seems to use different terms for each level. > > Roy Lambert > Hi Roy I haven't done anything about it, but have thought about doing something similar. It occurs to me that you could use the "Description" field in the Information.TableColumns table. You could allow users temporary administrators privileges to allow an ALTER TABLE statement. In your code, substitute label names and grid headers using something like the SQL below SELECT COALESCE(Description,Name) AS "Label" FROM Information.TableColumns WHERE TableName = 'MyTable' AND Name = 'MyColumn' Put (say) '{%Skill' in the label or column.title.caption. At form create, run through all components looking for captions starting with '{%' and substitute the text. (I do this scan through components anyway to adjust column widths and order in grids.) Having typed that up ... why use the Information.TableColumns? Just use a straightforward table. Cheers Jeff |
Mon, Jun 27 2016 5:03 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jeff
Thanks for that - its going pretty much down the approach I was thinking of. I'm also going to see if there are any freebie internationalisation packages around. Roy Lambert |
Tue, Jun 28 2016 9:14 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it? >> Some customers use the Description attribute of columns for such purposes. If you turn on this property, then EDB will use the description for field labels: http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelphi&version=XE&comp=TEDBDataSet&prop=AutoDisplayLabels I would imagine that the descriptions don't change very often, so it's not like you'll be altering the tables often. Plus, it only affects the database catalog, and not the actual table files. Tim Young Elevate Software www.elevatesoft.com |
Tue, Jun 28 2016 10:07 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
Thanks - I'd forgotten that one. Roy Lambert |
Sat, Jul 9 2016 4:58 PM | Permanent Link |
Jan Ferguson Data Software Solutions, Inc. Team Elevate | Roy,
What I have done in the past is to name the fields like NValue1, NCaption1, NValue2, NCaption2, NValue3, NCaption3 (where "N" is the general description of the field...like BackgroundValue1, BackgroundValue2, etc.) and then I allow them to change the caption of the label of the field. I use the Input Dialog Box to have them name the caption and I save that in the database under the NCaption fields. When the form is created I use the caption field data to populate the captions. I have been successful in doing this. The highest number of fields I have done this with is 20 (not including the corresponding 20 caption fields). Jan Roy Lambert wrote: Anyone out there give their users the ability to use aliases for the field names? If so how did you go about it? |
Mon, Jul 11 2016 6:12 AM | Permanent Link |
Adam Brett Orixa Systems | Roy,
I am not sure about using the system-field "Description" in the way you describe. Perhaps I haven't exactly understood your requirement. I had a phase of using the "Description" field, but found there were a few draw-backs. These may not be problems in your use-case: 1. All edits/updates require full locks of the data-table, as you are changing system meta-data. This makes it hard to update any system that is permanently live. 2. All edits/updates create changes to the catalog of the database, meaning that some backup / restore and update / replication processes are more complicated if you are changing field Descriptions. However, if you are talking about a once only change for each system, i.e. in the installation phase, after which users would not change it again, I think it would work well. |
Mon, Jul 11 2016 8:23 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< 1. All edits/updates require full locks of the data-table, as you are changing system meta-data. This makes it hard to update any system that is permanently live. >> I just looked at this and you are correct. However, this is a bit of a bug, because EDB *shouldn't* be locking the table when only the descriptions are changed (it definitely knows). I'm doing a new build soon, and I'll include the fix for this in the new build. Tim Young Elevate Software www.elevatesoft.com |
Fri, Jul 15 2016 4:34 AM | Permanent Link |
Adam Brett Orixa Systems | Tim
That would be super cool. I have pulled back from using the Field.Description because of the issues with updating requiring a full lock. It would be great to be able to use this as a feature. I would actually like to put in a user-editable Field.Description, so that managers can add explanations / help relating to the field for staff using it. Adam |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |