DT3 Encrypted Databases: Migrating Data & How to Change Password

In DT2 when a user launched the app they were asked for a password to access their databases. The series of DT3 betas I’ve evaluated never asked for this password, but I noticed the Encrypted Database creation feature and I immediately understood why no password was being requested. With so many new features to investigate, I put off playing with an Encrypted database till today. Happily discovering that DT3b6 includes my requested vertical window minimum size reduction (thank you) my evaluation is going into full throttle so I can be prepared for upgrading a whole company of users. (BTW, is there an ETA for the gold master?)

I created an Encrypted Database and option dragged the contents of the original unencrypted database. I waited, beachballing it for a bit. The groups and files appeared but, the counts were off. Two entire nested groups were not there at all. Thankfully one of the first places I looked I found a missing link/no preview file. I’ve run into that before, only to find that the user changed the name of the file in the finder and the database index obviously could no longer locate the file. I fixed that no problem. I figured if there was one, there’s going to be others. I continued on group by group, drilling down to child groups and found the numbers off by 3 or 4 here and there in the hierarchy. I option dragged the few missing files. I found no more broken links. My guess is that when the copy process encountered the one broken link, it caused the whole copy process to result in error.

Another migration issue I encountered was that many replicants became duplicates in the new encrypted database. Thankfully the number was not too high and I was able to delete the dupes and re-replicate.

Perhaps option dragging was the wrong process for me to have chosen? In all honesty it was my first and only thought. I didn’t even look for an import/migration command. I selected all, pressed the option key, and got the standard green “+” added to my pointer. Thankfully I located the unlinked file quickly. Had I not found it quickly it could have taken me hours to unravel the mystery and fix it. I imagine this could be a disaster for many users with enormous databases.

I did look for another way to have accomplished migrating the data to the encrypted database and couldn’t find an import or migration command. Had I found one, I would have expected that the user would been notified with a message displaying counts: successful imported item counts, skipped items, etc.

So that’s my first issue which is intended to be feedback or suggestion in nature and perhaps even helpful to the development team. I solved the problem. My counts are now correct. All is good on that front.

Here’s the question. How do you change the password of an encrypted database. I can’t find any way to do that. What am I missing?

Thanks so much.

I’m loving the new version and really looking forward to the launch of the final release.


(BTW, is there an ETA for the gold master?)

Sorry, but we not comment on development timeframes.

How do you change the password of an encrypted database. I can’t find any way to do that. What am I missing?

If you’re referring to the password to mount the encrypted volume, you can’t.

If you are referring to the password used for syncing, this is set in File > Database Properties.

I’m talking about the encrypted volume.

As an IT professional this seems impossible to me. Folks screw up on passwords all the time. They don’t write them down. They forget where they stored them. They think they have it right and they don’t. It’s just human nature and as an observer of hundreds of users for years from all ages and all walks of life - password management is an achilles heel for most folks.

For this new feature to work properly for Database Administrators, there NEEDS to be an administration interface to deal with this inevitable occurrence. For basic security purposes it’s a necessary and standard mechanism for databases. What if staff leaves a company or someone is banned from accessing a particular database? Passwords need to be changed from time to time for all sorts of reasons. DT is a data warehousing product. In many cases it holds very sensitive information. The security of this info needs to be manageable and changeable and recoverable. What happens when someone forgets the password? This is going to happen. What then? There should be an Administration tool set. This should be protected by a Master Password and give Administrators the ability to edit or change the encrypted password. Without such functionality, I can guaranty it’s going to happen - folks will be permanently locked out of their database.

Also, you didn’t addressed the data migration method question or the fact that many Repellants became Duplicates after migration. Any thoughts?


Are you able to reproduce this using a small test database?