Q - We recently noticed a strange phenomenon where if I try to access Elliott column names in the ARCUSFIL, I find the Customer AR account is defined as CUS_AR_ACCT_NO and it is 24 digits.  See sample screen below:

I have an application to try to find out the available column names of ARCUSFIL through system table X$Field. In there, I found that the CUS_AR_ACCT_NO is broken into three parts: 

See sample screen below:

I am really confused as to why the column names are inconsistent.

A - In Elliott V7.5, CUS_AR_ACCT_NO was broken down as three parts: The main account, the sub-account and the department with 8 digits in each segment.  With Elliott V8, we are making it as one single column of 24 digits for consistency purposes.

The reason you see the CUS_AR_ACCT_NO in PSQL Control Center interface is because it gets the DDF definition from the <ElliottRoot>\Bin\DDF40 folder.  On the other hand, PSQL has a quirk: when it tries to locate the X$Field value, it retrieves it from the DDF in the <ElliottRoot>\Bin\DATA folder if it can find them.

In the old days, there were some legacy third party programs that only allowed accessing of the BTR files if the DDF files were in the same DATA folder. Starship was like that a long time ago. But then they changed to ODBC access, and that’s not the only case. There are some old DOS Btrieve utilities that are like that too. We don’t need to worry about those legacy programs anymore. Therefore, there is no reason why we need to keep DDF files in the DATA folder. So you should just delete the DDF files in the DATA folder.

Please see related KB article:

    https://support.elliott.com/knowledgebase/articles/2015522-an-example-of-ddf-files-in-data-folder-can-cause-p

EMK