Since going on the forum - which answered my question - I now get the message, ‘Break lock on the ‘Sykes’ database? Gramps believes someone else is actively editing your database. You cannot edit the database while it is locked. If no-one is editing this database you may safely break the lock. However if someone else is editing the database, and you break the lock, you may corrupt the database”. THIS IS ILLOGICAL. If someone else was editing it the lock must be switched off or inoperative, otherwise they would not be able to edit it. As things stand today the dashboard comes up but without the data. This did not happen last time I used it. Any suggestions (I haven’t broken the lock yet) ?
Gramps is designed to be a single user system. This condition happens when gramps is not shut down properly. Example: you killed gramps by turning off your Mac.
You just need to break the lock and then you can load your database.
You are not understanding the terminology. Like many editing programs,
when one person has a database or document open, the program creates a
lock that says no one else may open it until it has been closed. But if
the program is not properly shutdown or crashes due to an error, the
lock will remain in place and must be broken before the document or
database can be accessed again after the program is restarted. This
applies to many programs such as LibreOffice, not just Gramps.
Maybe we should consider a better way to lock the database. Creating a ‘lock’ file doesn’t lock the database from a RDBMS point of view - it just prevent Gramps connecting.
Yesterday I connected to the database using ‘DB Browser for SQLite’ while Gramps was running. In DB Browser I created a number of virtual indexes. Then still while DB Browser was connected, I made an update in Gramps and got a ‘Database locked error’. I disconnected from DB Browser, and then the Gramps update worked.
SQLite connection supports both ‘isolation_level’ and ‘check_same_thred’ for handling this.
We have a medium-term goal of allowing concurrent access to Gramps. This would enable us to remove the lock file, which would be nice as it often causes confusion.
It would require 3 changes:
Remove metadata caching. At present, this also causes data loss when Gramps crashes.
Avoid editors writing snapshots of objects. I already have a prototype which writes a JSON patch instead.