I have just purchased rootsmagic 8, I have never used this program before. I have made several mistakes and my numbers for people are all over the place. (1 - 9, 11, 21, 32, 33, 36, 37, 42, & 47 are all empty) My question is can I delete all and restart? Also, any tips on doing Maternal & Paternal trees? I get so confused. Thank you for any help you can offer to this Newbie!
It would be really nice if RM came with a sample database, like Family Historian does. You can mess around with that in any way that you want and use the built-in option to restore it.
This would give RM users the ability to try things out on a ânon-liveâ db before taking their meathooks to their live db.
1 Like
any file can be deleted and an empty new one created.
perhaps just put that file aside in case you can save some of your data.
if you are new to genealogy apps buy the 2015 RM7 manual from amazon or as a pdf from rootsmagic to get an overview of the old version.
consult the RM8 wiki which is a crude substitute for a real manual but is helpful.
2 Likes
With RM, there is no undo function. You can manually perform an undo by adding back in the things you deleted, by deleting out the things you added, or by changing back the things you changed. And of course, that really isnât an undo.
With many programs, you can âundoâ a session by not saving at the end. But RM saves as it goes and there really isnât a save at the end.
The other option is that you can make frequent backups. Having made frequent backups, you can restore from a backup that has the data back the way you want it. That more or less accomplishes the undo function without being an actual undo.
Well, there are variations on the theme of frequent backups. For example, you could make a new database on Monday, call it Monday, and type some data into it. On Tuesday, you could copy your Monday database to a database called Tuesday and then start working on the Tuesday database. If you make a number of serious mistakes, you could simply delete the Tuesday database and copy the Monday database to a new Tuesday database, etc. If you donât make any mistakes in your Tuesday database, you wouldnât delete it and instead you would keep using it. Except that on Wednesday you would copy your Tuesday database to a new database called Wednesday and start using the Wednesday database. But the new databases created in this manner effectively just create a chain of backups in a different way than using RMâs backup facility.
1 Like
RM save auto feature is probably a virtue for most users who are careless about saving. FTM has a change log feature that lets you undo each change but mac users can just use time machineâs ~hourly backups to recover their database from
earlier times.
I believe when this rolled out, it did not allow you to roll back each change, but instead rolled back ALL changed items to the point you chose. In your example, anything that happened after 7/8/2022 at 2:43:36PM would cease to exist. Has this changed? If not, one wants to be rather cautious about rolling anything back without fully understanding what else might be lost. However that really has nothing to do with the OPâs question.
Iâm not a Mac user, but I wonder how safe that really is. What I mean is that software such as Dropbox can create problems when it backs up an RM database while the RM database is in use. So I wonder if Time Machine might have the same problem.
Dropbox is usually blamed for something like âsyncing to the cloudâ while the RM database in use. But the actual problem is that Dropbox is backing up the RM database while it is in use. It just so happens that the backup copy is stored in the cloud, but that isnât the real issue. Rather, the real issue is that the RM database is being backed up at all while itâs in use. And in fact, Dropbox even makes a local and invisible copy of the RM database before transmitting the invisible copy to the cloud. So itâs during the making of the local and invisible copy of the RM database where the potential harm arises. Itâs hard to see how that would be any different than the copy that Time Machine is making.
Here is a link to a discussion about making a copy of an SQLite database while itâs in use. Remember that the RM database is an SQLite database. The discussion does not mention Time Machine by name, but the concept is the same. Discussion of backing up SQLite databases that are in use Item #4 in the list is the most definitive statement of the problem.
Looking at my changelog screenshot it seems you roll back changes by family rather than each individual item and person. Still useful if you realize a week later you made a dreadful mistake.
Jerry; time machine backup software just autoupdates a connected external hard drive with any and all changes on your computer over about the last 90 minutes. You change a system preference, take screenshots, modify your great novel, etc. All get captured and no cloud storage or synching is involved. Later when you need a particular file back or even your entire computer from an earlier time you just jump into time machine, find what you want and restore it. TM is just another dead simple feature of Appleâs OS. One caveat is that I personally have had serious problems with SSD external drives and time machine and use only good quality hard drives.
2 Likes
Per FTMâs website, it does indeed roll back all changes to just before you made the error. You then have to go through and pick out all of the changes that occurred after and that you wish to keep. This is a damn big undertaking for people who have a hard time opening the same file every time and instead they claim the program deleted their data.
Iâm not trying to be argumentative, but what you describe for Time Machine sounds like it has the potential to have the exact same problem with SQLite databases as does Dropbox. I interpret âautoupdatesâ to mean the Time Machine software reads the internal disk on your computer and copies changed files to an external hard drive. Well, Dropbox reads the internal disk on your computer and copies changed files to the cloud. Itâs not copying to an external hard drive vs. copying to the cloud thatâs the issue. Rather the issue is that simply that copying an SQLite database while itâs in use can corrupt the database.
Such corruption sounds like it is impossible, but it is not. An SQLite database is simply not a typical or normal file. I suspect that other database systems than SQLite have the same issues, but SQLite is the database system that I have the most experience with. Thatâs because two programs I use very heavily are RM and Visual Studio, and both of them use SQLite databases. You simply canât have RM or Visual Studio backed up by third party software such as Dropbox or Time Machine while they are in use without risking corruption of your SQLite databases.
Another issue is that even if copying an SQLite database while itâs in use gets lucky and doesnât corrupt the original database, the copy process might corrupt the backup copy. In fact, I think itâs much more likely that the copy process would corrupt the backup copy than that it would corrupt the original database. And the copy process doesnât corrupt the original database very often. The corruption of the backup copy of the SQLite database wouldnât matter if you never needed to restore from the backup copy. But if you tried to restore from a corrupted backup you then you have a corrupted database.
From your description, the one big advantage I would see using the Time Machine method to backup your active RM database instead of using Dropbox to backup your active database is that Dropbox would be doing the backup almost continuously whereas the Time Machine would only be doing the backup every 90 minutes or so. So the risk of corruption of an SQLite database from Time Machine is surely much less than the risk of corruption for Dropbox. But the risk of using Time Machine to backup an active RM database canât be zero.
I think you may be underestimating Time Machine - or perhaps more accurately the basic function built into the new-ish APFS (Apple File System) that has replaced the old HFS+ in the last few versions of MacOS.
APFS includes a snapshot mechanism where a snapshot is a read only copy - so not modifiable by any subsequent I/O - of the whole âdirectory structureâ of the system plus the changes to the data since the last snapshot that is created on the system volume. The changes are usually derived from the on-going system journal file of disk changes between the 2 snapshots - or probably more accurately the 2 chosen points in the system journal file.
Note that any data changes to disk are not made in-place but written to free space, so both the old and new copies exist. This happens at the disk block level. As you might guess, snapshots may consume considerable space on the system disk until they are deleted.
Time machine just triggers a snapshot and then copies the read-only copy to itâs backup disk in itâs own time, and in combination with previous snapshots, it has enough information to restore a system disk to the state as of the chosen snapshot. Other software may also use this mechanism and I use Carbon Copy Cloner which uses it to take occasional - ever 2 days in my case - incremental backups of all the user data on my Mac.
Iâm wary of such confidence⌠Everything in the digital domain takes time. RM/SQLite writes a temporary journal file when writing to the database file so that it can rollback to the state it was in at the beginning of the transaction if the transaction does not complete. The snapshot of the database is taken at a slightly different time from that of the journal so the two are no longer in sync. Thatâs the point Jerry cited as the most significant:
You cannot backup an open, changing, SQLite database and depend on getting a perfect uncorrupted backup. Because your backup doesnât take a snapshot of the database and its journal file all in the same instant, you will get inconsistencies.
Of the cloud-sync systems, the one in which I have the most confidence that it avoids this risk is Microsoft OneDrive which appears to suspend backing up RM database files for as long as they are âopenâ in RM.
Thatâs entirely possible. But the way Time Machine works still doesnât address either of the two issues I raised.
#1 When Time Machine triggers a snapshot, the snapshot makes a read only copy to its backup disk. So far, so good. In the process of triggering the snapshot, Time Machine absolutely has to read the live RM database that is being updated. For reasons that I donât understand and that make no sense to me, a program that simply reads the RM database while RM is updating it can cause corruption to the RM database. Somehow or other the read operation by the external program is blocking the update operation by RM and causing it to fail. And remember that an update operation by RM can involve multiple rows of multiple tables. So maybe RM is able to update one row of a table and fails on updating another row of the same table, or maybe RM is able to update one table and fails on updating another table.
I would repeat that this sounds impossible. Why doesnât a read operation by an external program such as Dropbox or Time Machine simply slow RM down rather than causing an update to fail? I donât know, but it happens. It has something to do with the way SQLite works. The way Time Machine works is surely totally safe on any other file types than a database file. For example, itâs surely safe on word processing files and text files and image files and spreadsheet files, etc. Anything but a database file such as SQLite, and those may have a problem.
#2 When Time Machine triggers a snapshot, the snapshot makes a read only copy to its backup disk. So far, so good. But the read only copy on the backup disk may be corrupt as soon as its made. For example, an RM update may require updating two tables. The Time Machine snapshot make take place after RM updates the first table and before RM updates the second table. By definition, the read only copy of the RM database taken by Time Machineâs snapshot in this case is immediately corrupt. In the unlikely event that you had to restore from this particular Time Machine snapshot, you would be restoring from a corrupt snapshot.
In both case #1 and case #2, the corruption would not be caused by any bugs in RM nor by any bugs in Time Machine nor by any inadequacies in the Mac file system or operating system. Rather, the problem would be caused by a timing problem. Namely, there could be a race condition between RMâs update operations and Time Machineâs snapshot operations. And there is no locking mechanism or other synchronization mechanism between RM and Time Machine to eliminate these race conditions.
From your description, I think such a problem would be really rare with Time Machine and would be much less likely than with Dropbox. The reason for the difference in risk is that Time Machine snapshots every 90 minutes and Dropbox snapshots continuously. But I donât see how it would be impossible for corruption to happen, even with much less frequent snapshots. Indeed, from your description I think most Time Machine + RM users could go years without a problem. But I just donât see how the risk is zero.
I totally agree. The way OneDrive suspends backing up RM database files as long as they are open in RM means that the race conditions I described can never happen. That makes OneDrive very safe with RM. But it also means that you donât get a OneDrive snapshot of your RM database until you shut down RM. For some users that could mean no OneDrive snapshot of their RM database for hours or days at a time.
Is it possible that Time Machine is smart enough to suspend snapshotting RM database files as long as they are open in RM? It wouldnât be RM database files that Time Machine was recognizing as being open. It would be the more general case of SQLite databases.
Several months back, Google replace their miserable âBackup and Syncâ stuff with a newer version of synching software, I think they bought some company and assimilated it. However, since switching to the new version of Google Drive, it appears to behave in a proper manner and suspend backing up the RM file while it is open.
I have only tested this off and on, but in watching what happens, it looks workable.
Isnât that the whole point - system crash results in a rollback, doesnât it? Restoring a TM version and restarting from it should result in the same action, I would have thought. Or there is a general problem if there is a system crash whilst a transaction is in progress.
Anyway, this is all a bit gory and way off the original topic. Not sure how we got here but âŚ
Sorry, missed Jerryâs long comments. Stimulating and thought provoking as usual - where does he find the time for all his comments and observations.
No, Time Machine doesnât copy the snapshot as it is being updated. The snapshot is a frozen version of the current data on the system disk that is effectively made read only and cannot be updated - there is no copy at that stage, it is the original existing data. I suspect - but do not know - that the freeze is achieved by picking the current point in the system journal file. Working back through the journal allows the data blocks that are to be included in this snapshot to be selected. Any subsequent file updates get written elsewhere to disk using free space and will be included in the next snapshot. The frozen snapshot that exists logically on the system disk is then copied in no great hurry - for example, it only uses an efficiency core (low performance core) on an Apple silicon Mac - to an external Time Machine volume.
I said I would shut up, so âŚ.
In answer to your question - YES you can delete ALL and restart. Give your database a name and start with yourself. You can Color Code your Maternal & Paternal lines different colors too. Good luck and have fun.
Time machine is a mac only software feature of the OS but I have not seen a file corruption problem with it. I think it takes a snapshot in time and then copies that with any changes waiting for the next cycle. It may even be smart enough to skip over actively changing files (this is Apple remember). Also for most of you as Windows users TM is irrelevant. Perhaps the Windows Backup feature is also functional for RM8 databases.