* Regular Maintenance Procedure
-
shoshk
- Famous
- Posts: 242
- Joined: 13 May 2015 16:28
- Family Historian: V7
- Location: Mitzpe Jericho, Israel
Regular Maintenance Procedure
My husband and I are trying to setup a list of regular maintenance activities which should be carried out on a daily/weekly/monthly? basis to keep our database healthy.
I'm interested in hearing what other people do.
Thanks,
Shosh
I'm interested in hearing what other people do.
Thanks,
Shosh
Shosh Kalson
- Mark1834
- Megastar
- Posts: 2146
- Joined: 27 Oct 2017 19:33
- Family Historian: V7
- Location: South Cheshire, UK
Re: Regular Maintenance Procedure
Relatively little regular maintenance. With its simple GEDCOM file format, FH does not need the regular compression that more traditional database products benefit from. From time to time (not scheduled, but maybe every few weeks) I eyeball the record lists to check for things like sources with no citations, media records with no links, etc. I also order sources by publication details to check for any obvious errors (mistyped details, superfluous spaces, etc). Check media for any broken links. Check places for errors or duplication.
It’s rather ad hoc, but is that the sort of thing you had in mind?
It’s rather ad hoc, but is that the sort of thing you had in mind?
Mark Draper
-
shoshk
- Famous
- Posts: 242
- Joined: 13 May 2015 16:28
- Family Historian: V7
- Location: Mitzpe Jericho, Israel
Re: Regular Maintenance Procedure
Mark,
Yes. This is exactly what I'm after.
As you say, classic database maintenence is not required, although, it probably wouldn't hurt to run Validate on a regular basis.
Backing things up is another obvious item on the list. This includes running backup (does it always need to be full?) as well as running the Backup Settings plugin.
I'm thinking that problem reports should be run on a weekly basis. It's much less daunting to deal with a small list. No matter how careful, errors always creep in. Data consistency, missing data, and sourcing are obvious candidates, as well as checking for broken media links, non-existent media files, etc. But, perhaps certain items don't need to happen on a weekly basis. Monthly could be sufficient.
Check Installed Plugins should be run on a regular basis.
Obviously, something we view as a problem, won't be a problem for somebody else. One of our standards is to attach media only to sources. However, when researching, it's often convenient or even necessary to attach media to a To Do or Research fact. But it shouldn't stay there in the long run.
My husband likes to work from lists. It helps to make sure that he doesn't forget things.
OK, it's the middle of the night and I'm starting to babble, but you get the idea.
I appreciate your input.
Shosh
Yes. This is exactly what I'm after.
As you say, classic database maintenence is not required, although, it probably wouldn't hurt to run Validate on a regular basis.
Backing things up is another obvious item on the list. This includes running backup (does it always need to be full?) as well as running the Backup Settings plugin.
I'm thinking that problem reports should be run on a weekly basis. It's much less daunting to deal with a small list. No matter how careful, errors always creep in. Data consistency, missing data, and sourcing are obvious candidates, as well as checking for broken media links, non-existent media files, etc. But, perhaps certain items don't need to happen on a weekly basis. Monthly could be sufficient.
Check Installed Plugins should be run on a regular basis.
Obviously, something we view as a problem, won't be a problem for somebody else. One of our standards is to attach media only to sources. However, when researching, it's often convenient or even necessary to attach media to a To Do or Research fact. But it shouldn't stay there in the long run.
My husband likes to work from lists. It helps to make sure that he doesn't forget things.
OK, it's the middle of the night and I'm starting to babble, but you get the idea.
I appreciate your input.
Shosh
Shosh Kalson
- Mark1834
- Megastar
- Posts: 2146
- Joined: 27 Oct 2017 19:33
- Family Historian: V7
- Location: South Cheshire, UK
Re: Regular Maintenance Procedure
Shosh,
You're clearly very familiar with Windows and its file structures, so you might want to look at the approach summarised here. Backup of both data and settings is completely automatic, so I don't need to run either the FH data backup or the settings backup plugin unless I want a more selective backup for transferring to another PC.
It would also be relatively straight forward to automate the more mechanical aspects (unused sources, broken file links or missing files, etc) either via a single dedicated plugin or external script. Some individual elements are probably covered already in existing plugins. A plugin has the advantage of highlighting the records affected directly, while an external scrip (which I would write in Python to interrogate the GEDCOM data file directly) could be automated and run in the background, but would only list affected records and files, not highlight them directly. A written checklist would have the advantage of making the user think a bit more about what they are doing, so perhaps end up understanding a little more about how FH works, rather than relying on other people's solutions.
The wonderfully open structure of FH means there are lots of options available, both internally and externally.
You're clearly very familiar with Windows and its file structures, so you might want to look at the approach summarised here. Backup of both data and settings is completely automatic, so I don't need to run either the FH data backup or the settings backup plugin unless I want a more selective backup for transferring to another PC.
It would also be relatively straight forward to automate the more mechanical aspects (unused sources, broken file links or missing files, etc) either via a single dedicated plugin or external script. Some individual elements are probably covered already in existing plugins. A plugin has the advantage of highlighting the records affected directly, while an external scrip (which I would write in Python to interrogate the GEDCOM data file directly) could be automated and run in the background, but would only list affected records and files, not highlight them directly. A written checklist would have the advantage of making the user think a bit more about what they are doing, so perhaps end up understanding a little more about how FH works, rather than relying on other people's solutions.
The wonderfully open structure of FH means there are lots of options available, both internally and externally.
Mark Draper
-
shoshk
- Famous
- Posts: 242
- Joined: 13 May 2015 16:28
- Family Historian: V7
- Location: Mitzpe Jericho, Israel
Re: Regular Maintenance Procedure
My database also sits on the cloud (dropbox).
I use Syncback for daily backups, so that's all automated.
I don't backup the registry values. Is it documented anywhere what I lose by not having this?
Is there any advantage to backup the database using the FH facility?
While I'm very proficient technically, my husband definitely falls into the 'user' category. He is constantly finding new and creative ways to introduce 'errors' into the database.
I think that using a checklist is the way to go for most tasks since, as you say, it will hopefully lead to greater understanding of the database and how fh works.
Shosh
I use Syncback for daily backups, so that's all automated.
I don't backup the registry values. Is it documented anywhere what I lose by not having this?
Is there any advantage to backup the database using the FH facility?
While I'm very proficient technically, my husband definitely falls into the 'user' category. He is constantly finding new and creative ways to introduce 'errors' into the database.
I think that using a checklist is the way to go for most tasks since, as you say, it will hopefully lead to greater understanding of the database and how fh works.
Shosh
Shosh Kalson
- tatewise
- Megastar
- Posts: 27078
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Regular Maintenance Procedure
See the KB Understanding the Scope of Features that explains what settings are saved where.
Essentially the Windows Registry holds:
Essentially the Windows Registry holds:
- Tools > Preferences > settings
- Various configured Column settings
- View > Standard Diagram Types > Ancestors / Descendants / Ancestors & Descendants / All Relatives / Everyone / Blank
- Diagram Options for the Core Standard Diagrams settings per User (as listed above)
- Window/Pane/Column sizes & positions (for many windows) are saved per User
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- dewilkinson
- Superstar
- Posts: 280
- Joined: 04 Nov 2016 19:05
- Family Historian: V7
- Location: Oundle, Northamptonshire, England
- Contact:
Re: Regular Maintenance Procedure
Just out of interest I run the Show Project Statistics Plugin every month and a couple of queries checking Living Flag still set for deceased people and vice versa. The plugin is good as it detects a wide range of possible errors and the queries occasionally highlight the odd data entry error. I also use the Search and Replace plugin to 'correct' a few regular typos I seem to make, hopefully the spell checker in FH7 will reduce these.
One thing I often fail to do is amend media entries if I rename or relocate a folder with images in and the Show Project Statistics Plugin highlights these.
One thing I often fail to do is amend media entries if I rename or relocate a folder with images in and the Show Project Statistics Plugin highlights these.
David Wilkinson researching Bowtle, Butcher, Edwards, Gillingham, Overett, Ransome, Simpson, and Wilkinson in East Anglia
Deterioration is contagious, and places are destroyed or renovated by the spirit of the people who go to them
Deterioration is contagious, and places are destroyed or renovated by the spirit of the people who go to them
- AdrianBruce
- Megastar
- Posts: 1961
- Joined: 09 Aug 2003 21:02
- Family Historian: V7
- Location: South Cheshire
- Contact:
Re: Regular Maintenance Procedure
Very recently I downloaded a query "Unsourced Facts" from the FHUG Downloads section https://fhug.org.uk/kb/download-type/query/fact/. This lists facts without a Source Citation. This was supposed to be just a double check because I was confident that my workflow wouldn't allow unsourced facts.
Oh, pride comes before a fall.... I have 51 unsourced facts - some are obvious - anything dated in a census year is probably from that census, so that's what I need to check. But some? Hmmm - a bit of work to do.
NB - I did have to alter the query a bit because I have an person attribute that is text solely intended to appear on a diagram - e.g. predominant occupation - very few of those are sourced, nor do they need to be since I'm just summarising Occupation facts. That fact type is now excluded - anyone may find they have similar necessary exclusions.
NB - I did have to alter the query a bit because I have an person attribute that is text solely intended to appear on a diagram - e.g. predominant occupation - very few of those are sourced, nor do they need to be since I'm just summarising Occupation facts. That fact type is now excluded - anyone may find they have similar necessary exclusions.
Adrian
- tatewise
- Megastar
- Posts: 27078
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Regular Maintenance Procedure
Do you know there is now a Fact Flag Preferred you could set on the predominant standard Occupation attribute?
Then that Preferred Occupation can be chosen for display on Diagrams.
Then you can get rid of your custom predominant occupation facts.
Then that Preferred Occupation can be chosen for display on Diagrams.
Then you can get rid of your custom predominant occupation facts.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- LornaCraig
- Megastar
- Posts: 2989
- Joined: 11 Jan 2005 17:36
- Family Historian: V7
- Location: Oxfordshire, UK
- tatewise
- Megastar
- Posts: 27078
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Regular Maintenance Procedure
My comment was for general consumption.
I doubt if Adrian will update as I think he is one of those waiting for the <para> <br> problem to be fixed.
I doubt if Adrian will update as I think he is one of those waiting for the <para> <br> problem to be fixed.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- AdrianBruce
- Megastar
- Posts: 1961
- Joined: 09 Aug 2003 21:02
- Family Historian: V7
- Location: South Cheshire
- Contact:
Re: Regular Maintenance Procedure
Although I think there are a few other things that I'd like to get my head around first but I'll wait until the dust settles before pondering a bit more and asking as required...
Adrian
Re: Regular Maintenance Procedure
I've recently used FTAnalyzer to check my GEDCOM. It pulled up a disconcertingly large number of errors that have crept in over the past 15 years of research that I'm now busy correcting. It has proved very useful in highlighting incorrect census entries, addresses, and places as well as questionable deaths, births and marriages. I addition, it has highlighted all those individuals where I do not have census entries, where there should be one.
- tatewise
- Megastar
- Posts: 27078
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Regular Maintenance Procedure
This is beginning to sound like a useful article for the new KB but not until the New Year 
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
-
shoshk
- Famous
- Posts: 242
- Joined: 13 May 2015 16:28
- Family Historian: V7
- Location: Mitzpe Jericho, Israel
Re: Regular Maintenance Procedure
Mike,
I agree that this is stuff that could and should in the kb (and not buried in a thread on the forum).
I would be happy to take the lead on this with, obviously, the assistance and input of others.
After the new year sounds like a good time to start. It'll give people time to contribute their ideas.
Shosh
I agree that this is stuff that could and should in the kb (and not buried in a thread on the forum).
I would be happy to take the lead on this with, obviously, the assistance and input of others.
After the new year sounds like a good time to start. It'll give people time to contribute their ideas.
Shosh
Shosh Kalson