Rootsmagic 8 and FTM 2019 both use links to media stored externally in Finder (windows explorer). This keeps the size small but the links break if you rename or move these files. Both programs sync with ancestry.
Heredis and mac family tree both store media in the database which increases file size but avoids the broken links problem. Neither syncs with ancestry. MFT was quite critical of FTM for their media decision.
My small 400 person file has 1GB of media so many people would end up with a 5+GB file. Opinions on which approach is better?
Much prefer to have the media stored outside the database. Apart from the increase in file size which may slow things down I also use the media for other purposes and not just RM so I would be storing it twice.
If I download media from FMP or Ancestry I name my saved file as I save it so I rarely have to rename files but when I have reason to I do not find renaming them to be a problem. I open the Edit Media window where the link is and at the same time open File Explorer where the file is. I rename in File Explorer and then rename in the link. Done.
Had not thought about the duplication needed to keep media available at the finder level for other programs like Preview (mac image manager). A large file would not slow down an M1 mac but would limit the ability to share such a file.
Also every so often an image file goes ābadā and cannot be opened by a genealogy program requiring you to duplicate/rename that file. If that happened inside a database file that could be bad.
Oh yeah! Back in my FTM tech support days, some versions of FTM actually added the image file into the database. It was a very common call because their file went ābadā. Fortunately, most instances would involve closing FTM, re-opening and exporting a GEDCOM which effectively stripped out ALL images, then import that GED back into FTM. I actually had someone with a 5 gigglebyte FTM database file, and this was 20+ years ago before hardware and RAM was quite what we are used to now. As I recall, the lady had been scanning her files at 600dpi and she had a truck load of files that she was trying to add.
I would not want, nor would I use a program that incorporated the media into the DB file.
Completely agree about separating media from database. That said, Iām using the new Google Sites (not for genealogy) and donāt see where pasted images go. On Google Drive, all you see is the site āfileā icon. That said, isnāt any drive file system a type of database? It all boils down to āthe bigger they are, the harder they fallā (if tripped up).
I also keep my media in a separate location and use the Media option to link to the folder where the media is stored, not the file.
In addition, I have folders for all my major families. Each folder has sub-folders for their children.
The folder are titled with their birth year and given/first name. When a daughter is married the folder is titled with their birth year and given/first name AND her married surname, ex 1928 Joan Beard shown below.
E:\Herrmann Genealogy\Halbisen Family\1785 Niklaus\1812 Niklaus\1838 Bernard\1901 Clara Winke\1928 Joan Beard
All my media files are titled similarly, year of event, type of event, given/first name, her maiden surname, her married surname, ex 1995 obit Joan Winke Beard.docx
For full credit, this method of storing media was suggested to me by Pierre Gllzinger, a Paris chef and genealogist from prob 20 years ago. I donāt even think RM3 had a hard-coded media field. RIP Pierre
That was about the time that Microsoft as trying to flog Windows 2000 as a consumer operation system. Windows 2000 used NTFS and if I recall correctly, you could pull off disk volumes up to 2TB which would clearly hold a 5GB file. You could also get Windows 2000 up to 8GB of RAM if you tried.
As for the bit about Google Sites and Drive, I am assuming that refers to another post because I am not sure what you are talking about.
A FTM user in 2000 was more likely to be on Win 98 as 2000 was aimed at business. Regardless, both were 32-bit and Microsoft imposed a 4GB limit on file size, still restricting 32-bit RM8 on Windows today although that would be a database of a very large population since image data is not stored in it. Moreover RM8 seems to crash at 2GB in RAM which is another limit for 32-bit applications.
My comment about Google Sites has to do with media being stored in a database. What I am presented with by the Google Drive āfile systemā is one āfileā for the site. When I open that file, I enter the Sites app and can choose Pages to edit, add, removeā¦ but I donāt see an underlying file system. Itās a database system of some sort to which I have only high-level access. Likewise, FTM with media stored in its database is one āfileā in the disk operating system to which I am granted only high level access. And a āfileā that we see listed in Windows Explorer is a metaphor for the way the database system that is the drive operating system presents the data and metadata residing in special and scattered physical places to higher level applications.
Something could go wrong in one of those scattered physical places. If it is in an image data block, it would have no effect on current RM operations except for some output that includes it, rebuilding thumbnails or backing up with media. If that image data was part of the RM database, the database system itself might detect its file is corrupted and halt completely. Thatās āthe biggerā¦, harderā¦ā saying.
Uh no, at that time computer manufacturers were actually was flogging Windows 2000 as a consumer (read NOT BUSINESS) operating system. New machines at places such as Best Buy came with Win 2K installed. I was there, i supported FTM, and a shed load of other Broderbund and Learning Company softwareā¦some which would not run on Win2k at all which really cheesed off customers.
Dell, Compaq, Gateway and probably others were producing consumer machines like this.
Of course the file system was NTFS which was not constrained like those with FAT32 file systems.
ā¦and keep in mind, FTM didnt use a relational database at the time in questionā¦so the rest of your speculation is a bunch of hot air. SQLite is not a real relation database, it is a flat file pretending to be one.