On 2008 Nov 16, at 19:53, jef chippewa wrote:
hi hi hi. (FMpro 8.5, mac)
in a recent overhaul, a single database (with only one table) was
split by the user into three separate files instead of into tables
within the original file. the structure is fine, but i need to
compile these files into 3 tables in a single DB.
i did a trial run on copies of the originals and know i will need
to clean up scripts, calc_fields and field definitions in specific
layouts, but i just want to see if there is anything particularly
problematic to look out for when i do the consolidation on the
originals; i have never done this and so am a little antsy about it!
also, isn't there a way to import the table/fields AND the data
they contain in one go? or do i really need to export from the
original file and import into the (new) target table?
You can make your life either easier or harder, depending on the
order in which you do things. Here are a few random comments, with no
pretense of thoroness:
(1) Always start with value lists. Unlike virtually everything else
in FMP, these do not permit easy importing from one file to another.
It's tedious to copy all the values from the current file and paste
them into the value list for the new (target) file, but that's what
you should do. Make sure the value-list names are spelled
identically. In particular, be careful of hidden spaces at the end of
the title. If you have a value list in an old file that derives its
values from a field which is unique to that old file, create a dummy
(placeholder) version of it in the new file; you can go back and
reassign it after you've imported that table from the old file.
(2) Create in your new (target) file a layout with a name identical
to every layout you have in the old (source) files. You don't have to
associate the layout with the proper table name (yet), and you don't
have to have any fields on it (yet), but you'll be glad that
something with that name exists when you get around to importing
scripts that refer to layout names.
(3) Make sure your target file has all the proper external file
references set up. If there's a file reference in one of the source
files, it should have a counterpart (with identical name) in the
target file.
(4) Examine the definitions of all the calculation fields in your
source files. Note any which rely on table occurrences that don't
exist in the new (target) file. Create dummy TOs in the new file
which have the same name, regardless of what they're pointing at.
(5) Import the (empty) tables from the external files.
(6) Define all the necessary relationships, including reassigning to
the proper table any of the dummy table occurrences you created back
up in Step 4.
(7) Import the data.
(8) Import the scripts. Pull in pretty much everything. If your
source file has Script A that refers to Script B, and you pull in the
former but not the latter, you'll have an error in Script A that
you'll have to fix. Now it may well be that, in the new file, you
want Script A to call a different script instead of Script B, but
it's easier to do that if you know what Script A was originally
pointing at.
(9) Go thru all the layouts you created back in Step 2 and reassign
them to the appropriate tables.
(10) Copy and paste all the layouts from the old files into the new one.
