The most recent used database is in directory 63b9c406 (see time stamp).
However, in addition to that there are also datasets in directory 62432b35v21 itself and in sub-directory 63b98e85, all with older time stamps.
It seems to me that Gramps made changes on the data path by itself. These changes are not made by my edits of the preferences.
Is there some logic behind it that Gramps creating a new dataset in a different location on its own?
If so, what are the conditions for these changes?
Perhaps some knows more about inner workings of Gramps with regards to this topic.
Thank you
Each time you create a new family tree, Gramps will create a subdirectory in the ‘Database Path’ directory with a sqlite.db and a few extra files. You can see the name of the family tree in the file named ‘name.txt’.
In the Family Tree Manager you should see two family trees.
The files directly in the ‘Database Path’ might be leftovers from an upgrade of Gramps.
It looks like you browsed the Database location in the Preferences down into the folder with the Hexidecimal foldername. Then created (or imported) a tree when the Trees were missing from the Family Tree Manager dialog.
Your path for the database should be 1 folder level upwards and show those hexadecimal foldernames.
First, Unload the current tree.
To correct the bad folder locations:
You can drag those 63b9c406 and 63b98e85 folders up to the mnt/nas_appsdata/GrampsData/ folder at the same level as the 62432b38v21 folder.
Then set the database path to mnt/nas_appsdata/GrampsData/
Now the Family Trees → Manage Family Trees dialog should start listing more trees.
Make backups and start cleaning up the excess foliage.
By the way, that 62432b38v21 appears to be have be manually (and inappropriately) renamed. Those folder names are supposed to be the hexadecimal Tree database handle. So the v21 appended at the end of the foldername appears to be someone messing with the foldername.
I am the only one who has access to the directories on the NAS and I didn’t create the directory 62432b38v21 it must have been created by Gramps.
Anyway as suggested, I ‘unloaded’ the family tree determined the latest db (based on the date/time stamp).
Moved it to a new directory DataDir located in …/GrampData/.
Went back into Gramps and changed in Preferences → Family Tree → Database Location to the new location (/mnt/nas_appsdata/GrampsData/DataDir).
However, now I can’t open this database.
It’s trying to open the recent database (from the old location, which is gone).
There is now function in Gramps to navigate to the ‘new” location and open the database without using the ‘recent’ database.
When using the option “Manage Family tree” (CTRL-O) I can only create a new family tree, not open an existing one.
I can’t follow the logic of Gramps as it relates how it is handling the database location.
Why can’t I transfer the current database to a new location (i.e. new Harddisk), changed the path to that new location and open it from there, ignoring all traces of a recent family tree???
The folder name is a hexadecimal integer equal to the number of seconds since the Unix epoch (1 January 1970, 00:00:00 UTC).
you probably tagged it as version 21 of 62432b38. Equivalent to 1,648,569,144 seconds since 1 Jan 1970. Which is 2022‑03‑29 15:52:24 UTC
folder 63b9c406 = 1,673,134,086 seconds, or 2023‑01‑07 00:08:06 UTC
folder 63b98e85 = 1,673,082,485 seconds, or 2023‑01‑06 12:41:25 UTC
The contents within the folder should not have been changed when moving those subfolders (63b9c406 and 63b98e85) up to the same level as 62432b38v21.
Be more structured in your experiments
You seem to be taking our directions and deciding to do something else. Do notDO that! You are doing too many changes at the same time. Run experiments until you understand the system and confirm your understanding is ACTUALLY correct.
Make a copy of the weird parent folder to a USB external storage before tweaking things.
Only change 1 thing at a time
A typical test:
Check the Manage Family Trees dialog to see which trees are listed
look at the database path in preferences
in the OS file manager, go to the database path.
look at the contents of name.txt textfile in each of the subfolders:
62432b38v21/name.txt
in 62432b38v21/
63b9c406/name.txt
63b98e85/name.txt
correlate which hexadecimal parent foldername corresponds to the human readable Tree names in the Family Trees -> Manage Family Trees.. dialog
exit Gramps
Move 1 folder containing a Tree name that you did not see up to the same folder level as the Tree names that you did see
restart Gramps
verify that the Manage Family Trees.. now shows that tree
if not, exit Gramps and undo the change
if it does, exit Gramps and move the other Tree name folders that you did not see.
At the point (with all the Trees visible in the Manage Family Trees dialog), you should grasp the relationship of the Preference database path to the hexadecimal foldernames. And you can consider moving the folders to some other location and resetting the path preferences to corespond.
Start a new thread for this digression … but only after successfully resolving the current problem.
This topic already involves a fairly complex and fussy workflow, so it is better to not to mix in another tricky, detail‑sensitive question in the same thread. Keeping each thread focused on on one issue makes it much easier to give clear, step‑by‑step help and avoids complications.
It seems that, with your detailed suggestions, I have resolved my problems.
Now I can access the family tree again.
Is my observation correct that the entry in references → family tree → database base location must point to a directory one level higher up than the (sqlite) database is actually stored?
i.e. (figuratively):
Preferences family tree datasbase path entry: …/GrampsData/DataDir/
actually location of SQlite database: …/GrampsData/DataDir/63b9c406/.
It is the path that to the directory contains subfolder which contain not merely the actual sqlite.db database file. The other 3 files (or 4, if there is a lock file) are all metadata about the Tree data in that sqlite.db file. They are all needed by Gramps.
