Family Historian User Group

Renaming the cache file hasn't helped either -- and it doesn't work on a project I didn't test in the beta where I'd expect it to find at least census matches.

I'm also having the problem -- matches that showed up in Beta aren't showing up any more. Refreshing Internet Services hasn't helped.

http://msdn.microsoft.com/en-us/library ... 15%29.aspx might be helpful -- I haven't had time to take a good look.

As might http://omeratay.com/onetastic/? which shows some macro capability for OneNote.

Is there an age mis-recorded in the marriage event? (I suspect you've checked but just in case...)

I use Residence, with start and finish dates (as you've suggested) and link it via citations to each individual Electoral Roll (each of which is a separate source). That way, if I find another ancestor in the same Electoral Roll, I can link to the same source via a different citation.

A couple of approaches are documented in the wiki:

http://www.fhug.org.uk/wiki/doku.php?id ... o_do_lists

I tried out OneDrive and went back to Dropbox very quickly -- the quirks in the way Microsoft have designed it to work, especially with their own applications, made if effectively unusable for me.

Another disadvantage of ONeDrive is that it doesn't support shared folders in the same way that Dropbox does. You can share a folder with another individual but the files are held in the cloud -- they don't get a local copy. http://answers.microsoft.com/en-us/onedrive/forum/sdfiles-sdsync/syncing-sh...

With OneDrive, I suspect you have to have also configured File History (WIndows 8) but the rollbacks are stored locally. I'm not aware of any equivalent in Google Drive.

DropBox: No file size restriction, encrypted in flight and at rest, support for a large number of platforms: Windows, Mac, most phones, some Linux (and therefore some NAS). Google Drive: 10Gb maximum file size, encrypted in flight but not at rest, Platforms: Windows, MAC, some mobiles, Linux is prom...

Only drawbacks may be the 2Gb file size limit, and some lingering concerns about the visibility of your data to Microsoft (it isn't encrypted in flight and at rest as, for example, is Dropbox data). They've made some promises to improve privacy, but aren't all the way there yet. Google, like Dropbox...

Cordwainer = Shoe Maker. http://en.wikipedia.org/wiki/Cordwainer

There are times I love a site where you don't have to show your workings
And you could make a question -- even self-answered -- out of this for another site -- just saying

John, no, it doesn't really matter what a persons ID is, unless you're using it to distinguish between two individuals of the same name (for example) or as a cross-reference form outside FH. If you simply want to keep tabs on how many people you've got in your file, at the bottom right of your FH wi...

Repost it as a false positive to Norton and let Calico Pie know -- so few users have both their product and FH 5.0.9 it seems to trigger their 'there may be something nasty in the woodshed' response without any good cause. http://community.norton.com/t5/Norton-Internet-Security-Norton/Clarification-...

You may have to modify your directory structure to arrive at a shorter file path -- or save to a directory "further up the tree."

How long is your directory path -- there is a Windows limitation of 248 characters on a directory path (and 260 characters on path+file name).

1. For the date, I use a "Date Range" instead of a single date. 2. For the events for which you only have Banns and not Marriage entries, I'd record the banns event but NOT assume the marriage went ahead. (Although there will often be a parish in which the banns were read but no marriage took place,...

I don't think FH was designed for evidence gathering I believe like most of the Family Tree Software it is designed for recording conclusions. True, whish I why I use my own package for managing the process of gathering evidence gathering, but rather than duplicate functionality, I use FH to record...

The only 'shadow facts' I have experimented with so far are the ones I created for the GRO BMD registrations, and that worked out well. I can see the logic of a custom 'Birth registration' event, but not a custom 'Birth assertion' that mirrors exactly the structure of the standard 'Birth' event.

Again, separating Events from Assertions in different Fact Types would solve [those] problem . We'll have to differ on this one; as I've said, I think it would introduce more problems than it solves, including: the work to define and maintain the 'shadow facts' which aren't limited to just birth an...

I try and offer solutions that work for as many features of FH as possible, while recognising that some users may not use them all. I'm in awe of the amount of effort and creativity you put into finding solutions -- and fully recognise that, as everybody's research process is different, no solution...

Helen suggests a separate Assertion Fact for every Source even where the Date is the same. No she doesn't, or rather, ESM doesn't: Q: Should each date be listed and cited individually? A: Yes, each date is an assertion. Once you record that assertion in your research notes, you then identify the ev...

There would need to be one standard Birth/Death Event with a best interpretation of the research assertions to date. This would be what appears in normal Diagrams and Reports . If I don't have a preferred conclusion or best interpretation for birth date or death date I don't want a misleading 'norm...

Or, you could adopt Elizabeth Shown Mills approach: To What Do We Attach Our Citations? and retain separate assertions for every citation.

No problems here -- have you experienced any?