Combining Files

Danny Kohn ( recommends the following steps to move functionality from one file to another:

  1. Rename table occurrences and fields in source file (throwaway file) to match target file.
  2. Copy any necessary custom functions
  3. Create any necessary value lists. These can be blank for now.
  4. Copy tables and relationships.
  5. Copy any necessary fields into existing tables.
  6. Check Calculated Fields
  7. Copy the value lists
  8. Create Blank Layouts
  9. Copy Scripts
  10. Copy Layout Objects and Recreate Layout-Based Script Triggers

Phil Caulkins (@PhilModJunk) has some good info at Claris Community (English)

I am going to start moving some functions to my POS. Any recommendations and/or cautions regarding the above steps?

1 Like

Hi Steve,

Not a direct answer to your question above, but certainly related:

I would recommend generating DDRs of the before and after versions of the files, and perhaps even a DDR or two as you work through your list.

That way, if you wind up with something that appears broken at the end of your process, you have the wherewithal to distinguish whether the breakage was pre-existing, or whether it was the result of the code migration.




Thanks @steve_ssh — I’m using Base Elements to review the DDRs and clean up cruft and broken links. I’ll make sure to run a DDR before I consolidate each feature. My early consolidations should be relatively simple but I’m interested in perfecting the process in preparation for consolidating more complicated functions.

1 Like

@steverichter Here is a list I've last edited around 2014, you now get to use the clipboard for some more items (like value lists and custom menus):

  1. External file refs (if anything is to remain external) – Copy and Paste
  2. Custom Functions – Copy and Paste or Import
  3. Tables – Copy and Paste or Import
  4. Graph – Manual Fix. Make sure relationships and names are setup correctly
  5. Adjust Fields – Any fields that needed relationships will be need to be adjusted. One way to do this is to delete all the fields and re-copy and paste the fields from the old file to the new. That will break relationships, but those might be easier to fix than all of the broken calcs.
  6. Value Lists – Copy and Paste
  7. Adjust Fields using Value Lists as validation – Manual
  8. Layouts – Manual make the layouts with the correct names. Skip content for now. That comes later
  9. Scripts – Copy and Paste or Import
  10. Themes – Import ( Technically these can go any time before step 9)
  11. Layout Contents – Copy and Paste content, manually set sizes and parts.
  12. Layout Based Script Triggers – Manual
  13. Layout TAB order – Manual
  14. Layout custom margins / columns when printing – Manual
  15. Security ie Accounts and Privilege Sets – Manual
  16. Custom Menus – Copy and Paste
  17. File Options – Default Passwords and Window Based Script Triggers

There are some elements that can bite you either way, so for each specific project, you may want to alter the sequence a bit or do multiple pass. There are things that are difficult to avoid altogether. For instance, fields are required to establish relationships, valid predicates or not, many field options can use relationships (calc, auto-enter, lookup, validation, just about anywhere you can fit a calculated expression), Value-Lists require fields, but fields can also require value lists as a validation, etc. So there are a bunch of "catch 22" scenarios and you will need to look at your specific scenario to figure what is best for you.

Also, watch for possible name conflicts:

In some cases you may want to skip creation altogether (if you have a Yes/No value list in both files, making a replica may not make much sense, objects should simply get mapped to the one value list you already have in your destination file).

Some other times you may have objects that, even if they had the same name, were not conflicting because they were in different files (TOs, layouts, scripts). It could be good to rename using a prefix or suffix with the source file name before moving things around. In some cases, you may even opt to apply that renaming protocol to every object even if they are not conflicting.

Keep in mind that naming conflicts are to be handled for ALL the files involved in the consolidation, not just pairs of files. So if you are consolidating files A, B and C into file A, you want to avoid naming conflicts not only between A+B and A+C, but also with B+C given how B+C will both get consolidated into file A.

Additional reading:


@steverichter I know we are on a holiday and people may add to this discussion. That said, if you feel like my post answers your question, I would appreciate if you would mark is as an answer, unless it was not meant to be in the ER, in which case you can simply move it to a different channel. Happy Easter everyone!

1 Like