Using the Data Migration Tool, FMDataMigration -version 19.1.3.315 on a Mac running macOS Catalina 10.15.7
EDIT:
UPDATE: I have been unable to reproduce the issue, after more testing. - See below. Good news is that everything is working now.
End of EDIT.
I have been trying to get the data migration tool to work using [Full Access] account credentials on an encrypted file without success. Following the documentation I created an extended privilege set with the keyword fmmigration, and assigned this to a user, in both files before cloneing. Using this special user's credentials, not the [Full Access] user credentials, the data migration tool work as expected.
So, I have things working now, but I was wondering if this is a bug or a feature? If it is a feature it seems to be undocumented. - Has anyone else had this issue? Or is it that the tool no longer works with [Full Access] credentials on encrypted files?
I did a test on an unencrypted file with the default Admin [Full Access] user, no password, and that also worked fine. Does an encrypted file now require a user with the fmmigration extended privilege?
Attached is the sample Contacts file.
I encrypted it.
Saved a Copy as a Clone ( make sure you do not open this file )
Copied the DMT to that folder ( just for convenience )
Ran the below command.
@jormond - thank you that works fine, as expected. I will keep working on my 2 files that do not work as expected to see if I can find the issue. Very strange!
If you add the verbose switch, what error are you getting?
this was with my problem files - not the test file you sent:
I will have another go tomorrow (getting late here) and let you know - basically the error I was getting was with authentication of the migrated file I believe.
@jwilling - I am using zsh. using single quotes around the parameters is a good idea. In this case though it does not help, this was not the issue. See below...
The [Full Access] user password started with a number. Changing the [Full Access] user password to start with a letter has solved the problem.
I had the same problem on 2 different files, both using a [Full Access] user password starting with a number. In both cases changing the password to start with a letter has fixed the problem.
I have not tested with a [Full Access] user password starting with a symbol - I do not intend to test this, I'll stick with a letter.
Note that the [Full Access] user password that works does contain these symbols .*
Note that the password for the special user with the fmmigration extended privilege set does start with a number and that works fine - this just seems to be an issue if using a [Full Access] user account starting with a number.
My solution: If you plan to use the data migration tool with a [Full Access] user credentials make sure the password starts with a letter!
If you add the verbose switch, what error are you getting?
Couldn't open the source file because "(212): Invalid account/password."
Source: Contacts.fmp12
Are there any special characters in the password? Sometimes characters like % especially cause issues.
This was not the issue in this case, but are you saying don't use special characters in a [Full Access] user password? Or are there specific special characters that should or should not be used? Is this documented somewhere?
There are some special characters that can cause an issue when being processed in FileMaker itself. Actually, your first-character-number password falls into this category. Most are fine, and FileMaker handles it fine. When getting into some CLI commands, it all depends on how the password is processed. It seems in this case, the command gets confused by a number being the first character.
We had a similar problem using a ‘£’ sign within, not at the start, of the EAR password. I reported this on the original forum, but have no idea whether that post still exists.
From memory, we also had problems migrating from a non-encrypted file to an encrypted file and issues with missing externally referenced files that resulted in the log telling us the file was not safe to use.
Sorry this took a while... After some sleep and some coffee I did some more testing. I am unable to reproduce the issue using different files today. I don't plan to report this as a bug to Claris at this time as I am unable to reproduce the issue.
The good news is that everything is working now.
I feel like a fool for time wasting here.
Thanks for all your help.