You can use the Database Import Utility in Data Dictionary Maintenance to import the data dictionary information from your external table into the dictionary files. Once there, the table can be selected in the query from the regular list of table names, and you can mix and match external and native files.

This looks like a somewhat complex scenario to set up to try to duplicate what you describe. Perhaps it would be better to create a helpdesk ticket with sample panel and program to help us duplicate the issue:
https://helpdesk3.pvxplus.com/

The limit is 127 characters (i.e. the maximum length of a variable name).

I created a file with an external key where all fields were delimited, and the key was the first field. I then wrote some records where the key and first field were padded. I then updated the file using a dictionary update, and the spaces in the key were lost, like you said. This is expected, as the key field was delimited, and the last segment of a delimited key will be stripped.
I then went into Dictionary Maintenance and changed the first field to be 'Last Substring' and did a dictionary update which copied the data. The result was that the key remained padded, as well as the first data field. So you should try changing the format of the key field to 'Last Substring'.

If this doesn't work for you, you might consider attaching an embedded IO procedure to your file that would intercept and control your I/O procedures:
https://manual.pvxplus.com/page/PxPlus%20User%20Guide/File%20Handling/Embedded%20IO%20Procedures/Overview.htm

I need some clarification. You say:
"If we need to update the file, however, the key value is stripped of trailing spaces in the updated file..."
Are you referring to updating the file within File Maintenance, or some other way like a dictionary update?

Last Substring will pad and add a delimiter when written. It's only when reading that the data field is stripped.

If you want it to be fixed but with a delimiter, try defining the field as Last Substring. In the data it will be treated like Fixed with a delimiter added, i.e. padded when written and stripped when read. The external key value will be treated as padded.  See:
https://manual.pvxplus.com/page/Data%20Dictionary/Data%20Dictionary%20Maintenance/Element%20Description.htm

If it's just one user, it could be something in their query user profile, i.e. something in the options they have set for themselves in that particular query. You can see what options are set using the Query Profile Information Maintenance utility, which you can access through the Nomads Utilities menu, or through the IDE Graphical Application Builder > Utilities menu.

Enter the directory and library where the query is located, the query that is affected and choose the User. This will display the information that has been saved for the user. If there is anything listed under Info Type it may be causing the issue, so you select it and delete it and re-run the query to see if that was the issue.

If the version is 13.10, then line 1875 is:
1875 LET _HideCol=NUM(_HideOpts$(i,1))
Error 42 would indicate that the subscript i is out of range. The _HideCol array is dimmed to 200, so if you have more than 200 columns in your query, this would cause the issue.

I don't know if this would be applicable to your case, but you might consider using the Report Writer as it can create HTML output.

For more information on Calculated Fields, see:

https://manual.pvxplus.com/page/Report%20Writer/Designing%20a%20Report/Defining%20the%20Data/Calculated%20Fields.htm

Or check out the new training manual at:
https://home.pvxplus.com/files/7068/Introduction_to_PxPlus_-_A_Hands-On_Training_Guide_for_Developers.pdf
and search for 'calculated fields', or go to page 218.

Suriakumar,
There are two types of calculated fields:

• Formula - Contains a PxPlus expression that will be evaluated when the report is being generated. You can then define a Filter that will use the calculated field in its condition. For example, you could create a calculated field TOTALCOST that calculates COST+TAXES which can then be displayed on your report. Or you could define a Filter to only display the records where, for example, TOTALCOST > 1000. Or you could use it to set up different Cell or Line displays.
• Translation - This allows you to specify several conditions which will determine what is displayed on the report. For example, you could create a translation called MyMessage where the condition BALANCE>0 returns "Balance Due" and the Default returns "Paid".

SURIAKUMAR,
The code you show is for adding parameters dynamically at run-time when the report is being generated. They exist while the report is generated and are not being saved.
My question is this: Are the parameters required for the report always the same? That is, are you always requesting the COMPANY in this case. If so, you would define that as a parameter in the report definition using the Report Designer. See the Data > Parameter menu item.:
https://manual.pvxplus.com/PXPLUS/Report%20Writer/Designing%20a%20Report/Defining%20the%20Data/Parameters.htm

After you have defined your parameter here it will appear in the data pane of the Report Designer, where you can include it in the report, or use it in filters, etc.

At run-time when you are generating the report, if you generate it using the CALL method with the runreport program, it will automatically display an interactive panel to enter a value for the parameter. If you want to enter the value programmatically, after you open the report you can use the 'SetParameter(parmName$,value$) method to set the value, where parmName$ is the name you gave the parameter and value$ is the value to be assigned for the report.

The input source can be any native PxPlus file with an embedded data dictionary, a PxPlus View, a Query Definition, or any other data source whose data can be accessed using a Custom Data Source Object. External databases, such as ODBC, Oracle or DB2, can also be accessed via Views or Data Dictionary defintions. So if you are not using a Data Dictionary, you could create a manual query to supply the data or a report writer Custom Data Source Object to supply the data.

The Report Writer does not have global variables and functions like *web/start_up. You pass values into the Report Writer using parameters.
If you are running a report interactively, you can use the default interactive parameter interface to enter parameter values. If the report is not interactive, you can enter the parameter values programmatically using the 'AcceptParameters() method.

Here's a sample non-nomads program that creates a grid with cells that use a calendar query:
 
PRINT 'CS',
  mygrid=1000
  GRID mygrid,@(20,12,40,10)
  mygrid'columnswide=3,mygrid'rowshigh=5
  mygrid'row=0
  mygrid'colno=0,mygrid'columnwidth=10
  mygrid'colno=1,mygrid'celltype$="lookup" ! can edit cell
  mygrid'colno=2,mygrid'celltype$="query" ! cannot edit cell
  WHILE 1
  OBTAIN (0,SIZ=1)'ME',*,'MN'
  IF CTL=-1999 OR CTL=4 \
  THEN BREAK ! X or ESC
  IF CTL=mygrid \
  THEN GRID READ mygrid,mycol,myrow,myVal$,myEOM$;
        IF mycol<3 AND myEOM$=$FF$ \
        THEN GOSUB Do_Calendar \
        ELSE MSGBOX myVal$,"Value" ! the EOM for the lookup/query button is $FF$
  WEND
  END
!
Do_Calendar:
  PROCESS "Calendar","*win/calendar.en",myVal$
  GRID LOAD mygrid,mycol,myrow,myVal$+SEP
  RETURN