Using RootsMagic 11.4.0.0 on a Lenovo laptop with 128GB of RAM, my database has over 1,000,000 names
When I try to Compact my database (I have been doing a massive cleanup of record formats, resulting in deleting a large number of duplicated events), I continue to encounter the “SQLite Error 7 - out of memory” message. The tool used to run (until about a month ago). I have run all the other tools successfully, but Compact does not work.
Any suggestions on how I can get this tool to run?
Are you using the 32-bit version of RM or the 64-bit version of RM? I suspect that you are using the 32-bit version and that switching to the 64-bit version would solve the problem.
That being said, here are some caveats and other discussion. The Mac version of RM is always 64 bit because Mac’s no longer support 32 bit apps. Windows still supports 32-bit apps. The reason that there is both a 32-bit version of RM and a 64 bit version of RM is that RM’s tool to import Legacy databases relies on a 32 bit library and Legacy itself is a 32 bit app. For that reason, it would make sense for any RM user on Windows who does not need to import Legacy databases to be running the 64 bit version.
But I am running the 32 bit version with my 40,000 person database where I never need to import from Legacy. The reason is that there have been occasional problems in the 64 bit version that are solved by using the 32 bit version. RM must be using code that tries to store 64 bit pointers into a 32 bit integer at times or something weird like that. And such problems could be coming from software libraries that RM is using rather than from the main RM code. So it’s a subtle and complicated problem.
RM’s Compact tool is simply using SQLite’s Vacuum tool, and it is the Vacuum tool that is throwing the error, not any code in RM itself. If you are already on the 64 bit version, I can’t picture a way to solve the problem.
It is not quite as easy as you might wish to determine whether you are running the 32 version of RM or the 64 bit version. The easiest way is probably to open the Windows Task Manager and look at your running tasks. If it says “32 bit” for RM, then it’s 32 bit. If it doesn’t say “32 bit” for RM, then it’s 64 bit.
No offense intended, but you are likely mixing up the idea of RAM versus SSD-storage device size. It is very highly unlikely you have a laptop with 128GB of RAM. I would assume you really have a laptop with a total RAM of 16GB (or 8GB) with a 128GB SSD-drive inside, because laptops with even more RAM , also typically come with larger SSD-drive storage drives like 256GB, 512GB, 1TB or higher.
Also, Error 7 is not so much about a specific individual hardware capacity, but rather about how complex and demanding the task at hand. The amount of address space used by the operating system to perform functions on a million people is more intensive upon the RAM and SSD, which have to work in conjunction to process cleanup and compaction.
That means you’d have to split the task down into smaller subsets of people to reduce the demand. So, for example, first do an immediate Backup. Close all other databases, but this problem one. Now, as a test, Create a fresh new RM database, Arrange the two opened database windows side by side and employ Drag n’ Drop to drag Yourself and everybody related to You across to that fresh database. Run the Compact. Does it still error out?
If not, there’s a likelihood You can work on that batch to reduce duplicated events, correct spelling differences in Given and Surnames, merge Place Names, Date mismatches, etc. EITHER back in the original or even in this temporary one. When the reduction starts allowing AutoMerge and Manual Merge to consolidate and still pass Compact, you have an idea whether those things will help the original or whether compacting in the temp database will allow you to shrink it down, followed by a second Drag n’ Drop of a Selection criteria (Group or Color Code) of those that are NOT related to You for the same treatment approach.
OR it doesn’t have to be about “related to You” but rather the first Drag n’ Drop could be Selection criteria for a Group or Color Code of everyone who has EITHER a Parent, a Spouse, or a Child. Trying several isolation approaches to filter down the duplication or reduce the demand (all the while having your Backup intact) may get you past this.
EDIT: Bear in mind that GEDCOM export (with Selection criteria) from this database to a new fresh database can also be an alternative (to Drag n’ Drop) to determine viability of these approaches.
I could be wrong, but I took the 128GB RAM literally. Such machines do exist. And I suspected that such a machine might be in use in support of a database of over 1,000,000 individuals.
But no matter the exact hardware configuration, the problem still is going to come down to the ability of an SQLite Vacuum to handle a database of that size. It is certainly possible that a drag and drop would work, but I’m not sure how the “new drag and drop” works internally. The “old drag and drop” used GEDCOM as its transfer medium. The “new drag and drop” is doing database level copying of database records. But the details are completely unknown to me. The Drag and Drop may or may not run into to the same SQLite 7 error as the Vacuum, and I’m not sure if the “new drag and drop” maintains records numbers as you can do with GEDCOM.
In any case, I think the RM HelpDesk will have to become involved in this problem. For example, there may be an application-level PRAGMA setting in the database that is preventing the Vacuum operation from using all the memory or disk space it needs. Or the disk could be out of space. If it’s really a 16GB machine after all and the 128GB is the disk size, then 16GB may not be large enough to do a Vacuum that large. There are a lot of possibilities.
Disc space could be a problem with a database containing 1,000,000 people (and all their associated records)
“To run the Vacuum command, you need free disc space equivalent to at least double the size of your original database file. SQLite works by rebuilding a fresh, compacted copy of the database. During this process, it stores the new data in a temporary file before overwriting the original.”
The point by Steambuff is definitely a factor. You should certainly consider clicking Start menu button and type in and run the Windows utility named Disk Cleanup, as well as consider uninstalling via Control Panel, any Program(s) that You no longer need or never have had a use for (to free up disk space for the process swap file to work with).
Additionally impacting such performance would be other programs running at the same time that require resources. So, one could click the Start menu button and type in and run the Windows utility named Startup Apps and TEMPORARILY uncheck any that are not essential (to be later checkmarked again when done) and then reboot. Actually, one could try rebooting Windows into Safe Mode (to TEMPORARILY avoid many potential conflicting programs and services from running) long enough (to see if RootsMagic runs and gets further along).
Let’s start by asking how big the RMTREE file is and by asking how much free space is on the disk. Likely, it’s plenty. But it may not be.
Then let’s confirm whether it’s the 32 bit version of RM or the 64 bit version of RM.
Then let’s confirm if the machine’s memory is really 128GB or if it’s more like 16GM or 32GB.
I don’t think the more extreme measures are warranted until those questions are answered.
if they have 128 gb ssd (or other ) hard drive they might only have 8GB of RAM. Most people are not going over 32GB of RAM (at least majority of time)
For the doubters as to my hardware configuration, please see the screen grab taken from my machine tonight:
I don’t begrudge anyone questioning this, but I actually do have a machine with 128GM of RAM, precisely because of the size of my database (30 years of research and each name typed in individually).
Regarding some of the other comments, I am indeed running the 32bit version of Rootsmagic 11. I am going to pursue this line of inquiry to see if that resolves my issue. My question remains though compounded by why the utility worked up until about a month ago.
Thank-you to everyone who responded, you have given me some hope that this issue is solvable.
Have a Happy 4th of July holiday.
okay you are a TOP 1%+ impressive
so as others have mentioned might try 64gb of app because of 32gb ver memory access issues
VACUUM as AI mentions below might be worth trying – you may want to see what others suggest and make sure you have backup copies of database (including manual backup external drives and not through RM program)
AI said the following:
SQLite Error 7 - out of memory using RootMagic tools 32bit version of Rootsmagic with computer following specs
That is a monster of a PC setup you’ve got there—128 GB of system RAM, a top-tier i9 processor, and plenty of NVMe storage.
However, you have hit a very specific brick wall: 32-bit architecture limits.
Even though your computer has 128 GB of physical RAM available, a 32-bit application can only address a maximum of 2 GB to 4 GB of RAM, regardless of how much memory is installed on the motherboard. When you use intense database maintenance operations (like the Compact or Vacuum tools) on a massive RootsMagic database, SQLite tries to load or cache more data than a 32-bit process can physically hold, triggering the SQLite Error 7 - out of memory crash.
Here is how you can resolve this:
RootsMagic offers both 32-bit and 64-bit versions for Windows. Moving to the 64-bit version will instantly unlock the ability for the program to use your 128 GB of RAM, completely bypassing the SQLite memory constraint.
How to switch: Download the 64-bit installer directly from the RootsMagic website and install it. It will safely replace or run alongside your current version and read your existing database files flawlessly.
Note: The only reason the 32-bit version is still offered on Windows is to support direct legacy imports from older software (like Legacy Family Tree, which relies on old 32-bit libraries). If you aren’t doing those imports, you should absolutely be on 64-bit.
If you cannot upgrade immediately but desperately need to finish your database cleanup:
Run other tools first: Run Check for Data Integrity, Rebuild Indexes, and Clean Share old templates first. Sometimes fixing underlying structural issues reduces the memory footprint required during a database Compact.
Close background applications: While it won’t change the 32-bit app limit, reducing overall OS overhead can sometimes squeeze just a tiny bit more virtual memory allocation from Windows.
External SQLite Compact: Because RootsMagic uses a standard SQLite format, advanced users sometimes open a backup copy of their .rmgc (or current database extension) file in an external 64-bit SQLite manager (like DB Browser for SQLite) to run the VACUUM; command manually, then open it back up in RootsMagic
You didn’t say whether you are using the 32 or 64 bit edition on windows .
agreed was not clear before – but in reply to me he stated
Thanks to everyone who responded and advised. Switching to the 64-bit software solved the problem immediately. I am so pleased!
give you had a large db and impressive computer specs that is not surprising. I was confused at first and thought it might be related to computer specs. Glad its now resolved
I did a bit of reading on memory usage by SQLite for large databases. Well, I don’t think SQLite is to blame for memory bloat. SQLite’s memory usage is pretty much independent of database size. However, if RM retrieves large amounts of data proportional to total db size, then there is a problem.
