Family Historian User Group

Hi,

I'd like to try out FH7, but am slightly alarmed that the installation instructions state it will upgrade my existing FH6 to a trial version of FH7.

Can I run both versions in parallel on one PC (if I avoid opening any FH7 project in FH6), or is this not possible (without resorting to running a VM)?

Thanks,

Andrew

Not possible I'm afraid as FH7 writes to the same program folders as FH6 so blows your old installation away.

If you decide to trial FH7, you should take a complete backup of FH6 settings with the Backup and Restore FH Settings plugin (or manually copy the Calico Pie ProgramData and AppData folders and two FH Registry keys), and also copy all your project folders to an alternative location as a project that has been opened in FH7 should never be reopened in FH6, even if you don't change anything.

If you decide not to upgrade, you can reinstall FH6 and restore your settings and projects. It's a bit of a faff, but it's the only option if you can't trial FH7 on a separate machine or in a VM.

Interested in your comment that a project that has been opened in v7 should never be reopened in an earlier version. I can see why it shouldn't be worked on in an earlier version after being worked on in v7, but would there be a problem if it was just being opened to read? I've just bought v7, but I was going to leave the older version on my husband's PC for now. He only uses it to read the project on 'his' side, if he wants to check something, and I give him the file on a USB. He wouldn't be changing anything, or backing it up to my cloud storage, and I would carry on working on my 'master' file, not the copy. Can you see any problems with that? Thanks

It sounds ok if the two PCs are isolated from each other and don’t sync to the same cloud storage. It would be a strictly one way sharing. Alternatively, there is an option in FH7 to export a GEDCOM in FH6 format, so writing that to a USB stick would be even better.

I do exactly that, I run version 7 as my Main, on my desktop computer, and run v6.27 on an old laptop, I use the plugin by Mike Tate "Export Gedcom File", select destination FH v 6.2 and then use that on my old laptop, I just copy the exported Gedcom and replace the one in my v6.2 project folder.It is only one way data transfer though.

Eventually I will probably buy a second licence and do away with v6.2 but I have problems with large reports in version 7 with missing image's etc. falling over running report etc. so I am reluctant to do that yet

Dave

One thing that you need to remember is that FH7 makes changes to the Gedcom such that it is 'unreadable' by FH6. I tried this out of interest and when opened by FH6 whilst seeming OK there were many corruptions of the data. If you want both they have to be completely independent but the files are not directly interchangeable.

Eventually I will probably buy a second licence and do away with v6.2

Remember that the standard FH7 licence is for TWO copies, used by the same person but not simultaneously, so you can install a second copy now if you wish. The new registration process in FH7 keeps track of your installations, and does not permit more than the licensed number.

However, you are probably wise to keep FH6 for the moment. It is a known issue for FH7 that it has problems with very large reports with multiple images. Hopefully it will be fixed in FH7.1, but it is common practice for software to be released with known bugs if the judgement is that it will not be an issue for the large majority of users.

As has been said, there are export options both in the File > Import/Export > Export > GEDCOM File command and the Export Gedcom File plugin that will produce an FH V6.2.7 compatible GEDCOM file, but if any new FH V7 features are used they will not migrate unscathed back to FH V6.

@Dave: To reiterate, the standard licence says "you may install it onto 2 computers (and no more than 2) if both computers are owned and kept by you, and no more than one person ever uses the software at any one time."
See https://www.family-historian.co.uk/licence-agreements which is for FH V6 but has not changed for decades.

[ Sorry, we posted together. ]

Mark1834 wrote: ↑

23 Dec 2020 10:45

Eventually I will probably buy a second licence and do away with v6.2

Remember that the standard FH7 licence is for TWO copies, used by the same person but not simultaneously, so you can install a second copy now if you wish. The new registration process in FH7 keeps track of your installations, and does not permit more than the licensed number.

Yes, I know, I have two laptops and have he second installation on my new one but thanks anyway Mark

I'm not holding my breath for fix for reports, it seems to have been ignored as not a problem

"Ignored" is a bit harsh. More likely to have been judged to be insufficient to delay the release of FH7 pending a fix. It may even be unfixable within the chosen FH7 architecture, but only Calico Pie can comment on that. Have you reported it as a bug in the release version? Don't assume they read these forums, so they can't act on what they don't know.

Mark1834 wrote: ↑

23 Dec 2020 11:55

"Ignored" is a bit harsh. More likely to have been judged to be insufficient to delay the release of FH7 pending a fix. It may even be unfixable within the chosen FH7 architecture, but only Calico Pie can comment on that. Have you reported it as a bug in the release version? Don't assume they read these forums, so they can't act on what they don't know.

Yes I have and I don't assume anything Mark, I have been around long enough to know that lol.

I created a ticket for this on the day FH7 was released, but the more who do so will add to the impetus for Calico Pie to do something. I also had email exchange with them yesterday stressing how important I thought this was.

dewilkinson wrote: ↑

23 Dec 2020 12:03

I created a ticket for this on the day FH7 was released, but the more who do so will add to the impetus for Calico Pie to do something. I also had email exchange with them yesterday stressing how important I thought this was.

I get the impression they think it is a Microsoft problem.

In Change Any Fact Tag plug-in (18355) I was rebuked for encouraging "opening multiple tickets for the same problem" but I'm with you that "the more who do so will add to the impetus for Calico Pie to do something".

"the more who do so will add to the impetus for Calico Pie to do something"

If it's anything like the software support desks I've run, duplicate reports get discarded (often with some swear words associated).

For users who were not beta testers and not FHUG members, how would they know they are duplicating an existing report?
That group of users is probably the majority of users.
Who were you swearing at, the users for their reports or the developers for the bug?
I'm not sure you can draw an equivalence between your experience and Calico Pie.

For users who were not beta testers and not FHUG members, how would they know they are duplicating an existing report?

On these forums, some people are actively encouraging people to raise duplicate reports, so those at least are known duplicates that could be avoided.

Who were you swearing at, the users for their reports or the developers for the bug?

The users, for raising tickets they knew were duplicates. (It wasn't me doing the swearing, by the way, but the support teams working for me.)

The process of prioritizing bugs for fixing can't depend on the number of reports -- bug A reported once can be much more important than bug B reported multiple times, if bug A (for example) causes data loss and bug B doesn't.

Consider also, 5 reports (say) of a problem in a user population of hundreds or probably thousands by now doesn't mean it affects "many people"; it means it bothers less than 5% of users (more likely less than 0.5%). So report frequency isn't a useful metric to use to measure importance, which is why we used to discard duplicates.

P.S. Re experience, I've run first line and second line software support teams ranging in size from 2 to 20 people. I think CP will fit in there somewhere.

I have worked in customer service for the best part of 30 years, the last few a marketing assistant at a theme park.

I find that the best way to avoid multiple reports of faults and or complaints, is to feedback to the customer, that is something that CP is very poor at. If we knew they were working on it, or even if they offered an explanation, we would not need to keep reporting it.

Of course, if Calico Pie had a 'Public Bugtracker' within the Registration Site then registered users would have a chance of knowing when a problem has already been reported/acknowledged; and would be able to add pertinent information to existing reports, rather than duplicating them. It would also be relatively easy for both Calico Pie staff and users to monitor what action has been taken/is needed without the necessitating individual e-mail communication. They obviously already have a logging system, so why not share it, with some clear but simple direction (template) on problem reporting?

Mervyn

Good argument - we know the numerator, so invent a denominator to suit your case...

Personally, I think discarding duplicates is extremely bad practice. When I used to run ISO9001 systems in a large multinational, frequency of similar reports was a significant metric that the auditors always asked for...

If we knew they were working on it, or even if they offered an explanation, we would not need to keep reporting it.

From experience, 'offering an explanation' is usually just fuel to the fire, especially if the answer is 'We're not working on it and don't intend to because...'

"How dare you say you're not going to fix my bug/can't fix my bug!" and similar rants that just eat more support resource and divert them from actually doing support. Users on these forums are reasonable people, but you'd be surprised how many people don't understand that software is never perfect and you have to live with some bugs -- look for a way of working around them, or look for an alternative product if you really can't live with a bug...

A bug might only be fixable if Microsoft (or MyHeritage or another supplier on whom the product is dependent) fix a bug in their product (which may happen sometime never); or it might need a major product change that could introduce more problems than it fixes for the sake of making something better for a very small number of users...

(I did once have the joyous experience of explaining to a customer that a bug wasn't our fault, but Microsoft's and suggesting they complain to them. I wouldn't normally have done so, but I suspected the White House had a louder voice than the developer I was working for. Bug still didn't get fixed!).

If Calico Pie had a 'Public Bugtracker'...

...they'd still be on a hiding to nothing. I certainly wouldn't expect them to allow write access to their own bug tracker -- a recipe for disaster! Read access? To 18 years worth of bug history, in a product which probably isn't designed for access by hundreds of external users? I don't know what bug tracker they use, and some of them do have pretty front ends for web access, but there's the effort involved in implementing and maintaining the front end... and they may be running a very simple sql database on an internal server, so implementing a Public Bugtracker would be a big project. I'd rather they put their effort into updating FH. And of course fixing the important bugs.

Mark1834 wrote: ↑

23 Dec 2020 14:19

Good argument - we know the numerator, so invent a denominator to suit your case...

That's why I included the example of a hundred users to give a likely worst case. But we could invent a numerator as well if you like

Personally, I think discarding duplicates is extremely bad practice. When I used to run ISO9001 systems in a large multinational, frequency of similar reports was a significant metric that the auditors always asked for...

Context matters. Why was it a useful metric in your context?