FMDataMigration -ignore_valuelists parameter behaviour

Lounge (Discussions)
1

A data migration planned for this weekend required us to have detailed knowledge of the use of the -ignore_valuelists parameter.

The definition of this, is that if included in the syntax the new file created uses custom value lists from the clone instead of the source file. By not including it, the new file uses the values lists from the source file.

The behaviour meets our requirements, which we were pleased about, but there are a couple of ‘gotchas’ that perhaps not everyone is aware of. Here are our test results:

Results observed in the new file created:

Retained:
For value lists with matching names, typed-in values within ‘Use custom values’, regardless as to what was in the clone, retain the values from the original source file

Change of position within the ‘Manage Value Lists’ list doesn’t affect the contents of the value list, source file values retained

Value Lists Changed
Value list that is changed from ‘Use custom values’ to ‘Use values from field’ (and presumably ‘Use value list from another file’) treats this as a structural change and the new file inherits the version from the clone (the original content is retained in ‘Use custom values’, but the radio button is no longer selected, which is the same behaviour had this been carried out manually). Swapping from ‘Use values from field’ to ‘Use custom values’ behaves the same, replacing the source value list with the clone’s.

If a value list has been renamed in the clone AND the ‘Use custom values’ contents are ALSO changed, this is again treated as a structural change and the new file uses the values from the clone. Fields retain renamed value lists. (Beware if you have a customer who can change value list names!)

If a value list has been renamed in the clone AND the ‘Use custom values’ contents have NOT been changed, then the new file uses the clone’s value list name, as above, but of course the data is the same in both.

As mentioned, the results are pleasing to us, but a couple of the results may catch one or two of us out.

Regards
Andy

7 Likes
2

Great work Andy, thanks for sharing!

Now that transactions are available in FM (a long-standing developer request), there may be hope for a clear data / ui and logic separation that will make the DMT obsolete and streamline the development process tremendously.

3

Thanks @Torsten, I wish I had more time to do more of this.

Regarding DMT and data/ui, all of our systems have been separated for at least the last 15 years and we used to do ‘drop in’ upgrades all the time.

However, We rarely bother doing this at all these days. DMT removes the problems of getting fields in the data files getting out of sync and user account mismatches, for instance.

We are huge fans of the FMDataMigration tool, and we continue to be committed to the data separation model (normally 1 UI and 3 data files). Since DMT’s release it has resulted in a massive productivity boost for us, particularly with the addition or the -target_locale parameter for us non US residents. We believe it to be one of the best tools Claris/FileMaker have provided us with and they should be given full credit for that!

1 Like
4

I also use separation. why 3 data files?

5

I wondered whether anyone would ask this question as I was typing. The majority of our solutions are built around, or are (SBA), our SaleFaith CRM. The 3 data files are:

Data - all the pure database and configuration data

Comms - All the communications tables, such as email, letters/documents, telephone notes, communications join table, tamplates, etc.

Documents - tables with container fields for externally stored email attachments, Word (merge) files, PDF files, image files amd email attachment files.

The (most important) Data tables are kept as small as possible and away from the other functional tables.

I hope that explains it clearly enough, but happy to engage further.

All the best
Andy