4. there are some Extremely helpful users on the forum who use SQL queries and edits on their RM database files (NOTE: do a backup and work on a copy of your database, even if you're an SQL expert)
I regularly use SQLite to work on my production database and I seldom take a special backup before using SQLite. And I think my approach is perfectly safe. Here's why.
About 99% of the time, my SQLite queries are just that - true queries that are not updating anything. It's very difficult to see how there is any danger in running true queries against my production database. My mode of operation is usually to run the SQLite query using SQLiteSpy, and SQLiteSpy runs in a separate Window from RM. Based on something I see in my query, I will make some sort of update in RM. I will then rerun my query so that it reflects the changes I have made, and then make some other update in RM, etc. Such SQLite queries run with one click and run virtually instantaneously. Doing this in some sort of test database just doesn't make any sense. And even if a true query messes something up in my RM database (which is really impossible), I have a very robust set of backup procedures in place which are more than adequate for recovery purposes.
There a lot of wishes in this forum about RM reports being so-called "live reports". Most RM reports are very static reports that run in modal windows, and you have to move the reports outside of RM to be able to navigate in any kind of back and forth fashion. The Find Everywhere report is a newer report which comes much closer to being the kind of live report I think many of us are looking for. Running SQLite queries in the manner I'm describing is not really running live reports. The SQLite reports have to be rerun. But rerunning them is so easy (one click) and is so fast (virtually instantaneously) and swtiching between the RM window and the SQLiteSpy window is so easy that the process has very much the look and feel of actually running live reports.
About 1% of the time (probably even less), my SQLite queries are actually updates. I find it curious that the SQL world tends to call any SQL script a "query" even when the "query" is really an update. In any case, I always develop a new SQLite update with a test RM database which I don't bother to backup. If I mess it up, I just delete it and recreate it. The first time I run such an update against my production RM database, I do make a special backup. But after the update has been well proven, if I use it again in my production database I usually just rely on my standard backup procedures and don't make a special backup.
Most of the time, I use SQLite updates to perform global replace operations that are not otherwise supported by RM. For example, I used an SQLite update to insert dummy private text at the end of every fact note in my database. The purpose of this update was as a workaround for a longstanding RM bug where it loses carriage returns at the end of fact notes upon a GEDCOM export. But sometimes I use SQLite updates in a more targeted fashion. For example, I am gradually changing most of my sources from using the built-in free form source template to using source templates of my own development. (Even if you use the built-in source templates rather than developing your own, don't use them directly. Rather, use a copy.). So I use an SQLite update to change a Master Source from using one source template to using another. It's a truly trivial SQLite update that's very hard to mess up. This is a workaround for very a rather serious lack of function in RM's handling of sources where once a source template is chosen for a source, the choice of source template can never be changed.