Highlighted
Super Contributor.. Super Contributor..
Super Contributor..
390 views

Using concept of Logical Name Solution for other tables

Jump to solution

Hi,

I'm trying to reverse engineer the functionality of the Logical Name Solution and apply it to different tables. For instance I wan't to be able to show full names of users in qbe lists instead of their IDs, have them in one field and have them be automatically updated if the name of the user changes (getting married etc). 

The functionality is hard coded for the device table (script library DisplayName etc), has anyone tried this and could give me some hints where to look. The way it is implemented doesn't seem to be well documented. 

I've already enabled data reference check and checked the Entity Relationship Diagram, these seem to be setup fine, there has to be something that takes care of the display value/saved value translation, but I can't find out what it is.

Thanks, any tips or hits appreciated.

Peter

 

Peter Bartal
0 Likes
1 Solution

Accepted Solutions
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: Using concept of Logical Name Solution for other tables

Jump to solution

I assume it's hardcoded for a reason but I did do some experimenting with it during our implementation project. I wanted to view full names for contacts rather than their IDs. I'm not endorsing it but below are the steps I took. If you decide to try it, I'd recommend you do this in an environment you don't mind catching fire.

 

1) Update contacts datadict

  • Go to datadict > contacts
  • Using the RAD debugger, run x display.field in $L.file="full.name"
  • Save datadict record


2) Update probsummary datadict (this is the table I experimented with)

  • Here you need to update the reference.table value to "contacts" for the field you want to be translated. The tricky part is finding the correct position.
  • I used the debugger and ran d fields in $L.file and used the output here to determine my target field's position. For this let's assume contact.name was my target field and its position is 84. From debugger I could confirm this with d 84 in fields in $L.file and see that the return is "contact.name".
  • Now that I have my target field's position I use the debugger to run x 84 in reference.table in $L.file="contacts" (the reference.table position value will correspond with the field position value)
  • Save the datadict record, logout and back in

 


When viewing the contact.name field from a QBE or form you should now see the full.name value instead

I did this in my sandbox and ultimately decided to abandon it out of concerns of what other unknowns I might be impacting but it did appear to work. I tried the same method to make the IDs from the operator table also translate to full names and that one completely blew up on me when using fills. Contacts didn't seem to have that problem but I didn't have time for thorough testing.

View solution in original post

2 Replies
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: Using concept of Logical Name Solution for other tables

Jump to solution

I assume it's hardcoded for a reason but I did do some experimenting with it during our implementation project. I wanted to view full names for contacts rather than their IDs. I'm not endorsing it but below are the steps I took. If you decide to try it, I'd recommend you do this in an environment you don't mind catching fire.

 

1) Update contacts datadict

  • Go to datadict > contacts
  • Using the RAD debugger, run x display.field in $L.file="full.name"
  • Save datadict record


2) Update probsummary datadict (this is the table I experimented with)

  • Here you need to update the reference.table value to "contacts" for the field you want to be translated. The tricky part is finding the correct position.
  • I used the debugger and ran d fields in $L.file and used the output here to determine my target field's position. For this let's assume contact.name was my target field and its position is 84. From debugger I could confirm this with d 84 in fields in $L.file and see that the return is "contact.name".
  • Now that I have my target field's position I use the debugger to run x 84 in reference.table in $L.file="contacts" (the reference.table position value will correspond with the field position value)
  • Save the datadict record, logout and back in

 


When viewing the contact.name field from a QBE or form you should now see the full.name value instead

I did this in my sandbox and ultimately decided to abandon it out of concerns of what other unknowns I might be impacting but it did appear to work. I tried the same method to make the IDs from the operator table also translate to full names and that one completely blew up on me when using fills. Contacts didn't seem to have that problem but I didn't have time for thorough testing.

View solution in original post

Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: Using concept of Logical Name Solution for other tables

Jump to solution

Hi josh,

thanks for the reply. The described solution really works, but looks like it works only on the tables that have the data reference check checked by default. The contacts example was just that a example, my issue is with trying to do that for a custom table (not part of the OOB system). 

Thanks anyway, this gives me at least another hint. Now I see that the 7 tables that have this enabled by default will work. Now to find the details of the funcitonality.

Peter Bartal
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.