Release Date: 4/24/19
Version: All
Q - I've been asked to set up UPS Worldship to access customer shipping addresses in Elliott. I've run into a problem mapping City, State, and Zip fields to Elliott. Looks like Elliott concatenates these fields to the Ship-To Address 3 field. Worldship is unable to digest this.
What do you recommend?
A - You must be using a very old copy of DDF. As far as I know, Elliott DDF in 7.5, 8.x and above all have Order Ship to City, State and Zip fields separated with filler in between. Please download the latest Elliott version. By default, the Elliott installation Package does not override the existing DDF, so you need to use a custom installation to override the existing DDF. You may want to backup your existing DDF before you do that. One of the reasons we don’t install DDF when updating Elliott is because DDF is constantly open by users or the PSQL server. So you need to make sure no process is opening the DDF files before you try to install the new version. Elliott’s DDF is in either <ElliottRoot>\DDF40 or <ElliottRoot>\Bin\DDF40 depending on which Elliott version you are running. You can find out if any process is opening DDF files through the PSQL monitor utility.
Q - I found out we have DDFs all over. I’m assuming the DDFs in use are the ones specified in the PSQL database properties, right?
We are running EL800 and EL800P only, so my focus should be on <ElliottRoot>\Bin\DDF40 only, right? Looks like I’ll need to update the Dictionary Location. I also notice the mapped Data Directory drives need the path updated to point to the data directory.
There are at least 4 DDF directories in their installation besides the default locations you describe. Can I remove these as long as the Dictionary Location setting is set to <ElliottRoot>\Bin\DDF40 for all databases?
Any chance of things blowing up once the correct DDF files are in place?
A - Our typical naming conventions for the database are:
ELLIOTTDATA for V7.5 DDF which point to <ElliottRoot>\DDF40 folder
ELIDATA for V8.0 DDF which point to <ElliottRoot>\Bin\DDF40 folder
I can understand your concern that things may blow up if you keep the same database name and change the folder under the database properties.
I am not sure about the database name you use. Let’s assume you are using ELLIOTTDATA and point to an old DDF folder. To mitigate that risk, your best bet is to create a database name like ELIDATA that points to the <ElliottRoot>\Bin\DDF40 folder. Then migrate your application from using ELLIOTTDATA to use ELIDATA. If everything still works, great! If something blows up, then change it back to ELLIOTTDATA and take your time to investigate why it blew up and address it accordingly before using the new database name again.
The biggest changes of 8.0 DDF are the following:
- The GL account consists of three parts: Main, Profit Center and Department. The 7.5 DDF was defined inconsistently in this area. Sometimes it defines a GL account with three fields. Sometimes it defines the whole GL account as one field. In V8.0 DDF, we consistently define the whole GL account as one field.
- Some of the tables have columns like FILLER*. They are all now changed to TABLENAME_FILLER* where TABLENAME is the 8-digit table name. This is an effort to make sure there is not the same column name among different tables.
Whether these changes will affect your existing third party applications (i.e., Crystal Reports, Excel Query, Manifest System..etc.) or not is hard to say. Therefore, adopting the previously suggested steps to create the new database name that points to the new DDF files is a safer way to go. Once you have everyone migrated to the new database without issue, you can then disable the old database. You can do so by changing the database properties to point to an invalid location for the DDF files. If someone complains their application is no longer working without errors, then you know they are still using the old database name. This ensures all users migrate to the new database name.
Please also read the following related KB article: