Andy Hibbs

FMDataMigration Non Encrypted Original to Encrypted Clone

Discussion created by Andy Hibbs on Feb 5, 2019
Latest reply on Feb 5, 2019 by Andy Hibbs

I've not tried this on the Mac, and we have found different behaviours of FMDataMigration between Mac and Windows, but within Windows has anyone tried to migrate from a non-encrypted original using an encrypted clone (i.e a clone that has been encrypted and then saved as a clone again) to create a new encrypted file with the original data? We're using fm_data_migration_17.0.3.304 (can't find a newer version).

 

This has been brought about by the difficulties of encrypting FileMaker files with externally stored container files, which will result in the log reporting an encryption failure and that the encryption process has been skipped. We don't believe that this is actually the case and the log is next to useless. Instead, we believe the error is actually highlighting a missing linked file and that the file has actually been encrypted.

 

However, we don't like any errors of any kind in logs and in the past have spent hours trying to trace the missing file and deleting the record. After which the encryption usually works or finds another missing file.

 

As this is preparation work for an upgrade tomorrow, we thought we'd save clones of the original development files, add encryption at rest, which worked fine. Open these and then save as clones again, then use the migrator tool to take the file from the non-encrypted originals to create new files with data and EAR. This would give us encrypted development files and act as a dry run for tomorrow.

 

However, we are repeatedly getting 'the source file is not encrypted' after entering the syntax. We've tried leaving -src_key out entirely, entering speech marks, or just entering -src_key without anything after it, but can find no combination that works.

 

We seem to be stuck between a rock and a hard place at the moment. The originals won't encrypt without logged errors due to data (linked file) issues, so we need to clone them to encrypt, but we then can't get the data back in as the originals are not encrypted.

 

If we can't resolve this, then we'll just live with the errors in the logs after the EAR process, which we've done before, but would like to know if anyone has successfully achieved the above?

 

Many thanks

 

Andy

Outcomes