FileMaker misfeature with multiple relationships on same files

[anewc2]

The wrong items show up in one of the portals. We are using FileMaker 6.

Background: this is for our auction database. People buy stuff in the live auction and in the silent auction. So we set up a relationship between the file of bidders and the file of items for sale. But we want to print the live purchases and the silent purchases separately. So I set up two relationships between the two files. The items file has a field for live winner and a field for silent winner, and the two relationships are based on these two fields. (Any one item will have an entry in only one field.)

But what shows up in the Silent portal is several copies of one of the live purchases. The correct number of copies, one for each silent purchase. But the data visible in the portal is not correct. (The fields that count the silent purchases and add up their dollar amounts -- those are correct.)

Is there a solution/workaround for this in FM 6, or is it time to bite the bullet and upgrade?

Amos

[Fitch]

Double-check that the fields in the portal are from the correct relationship.

[Vaughan]

Time to upgrade. :

[comment]

Maybe, maybe not - surely it's not required to solve the current problem.

[Vaughan]

You're right... but it's certainly time to upgrade. I cannot recommend anybody doing active development work in FMP 6 and earlier.

[comment]

Seriously, why not? I'll bet I could find some old posts of you recommending upgrade to version 6. Has anything happened since to make it worse than it was when it came out?

[Vaughan]

Well for one thing, most people on this forum are beginning developers. So they'll be learning how do develop while they're doing the development. If they're using FMP 6 and earlier they'll be learning ways that are sub-optimal or obsolete for the new version (many things were done in FMP 6 only because there was no alternative) and then face the daunting task of having to un-learn the old ways before learning the new ways.

Other reasons include the availability of software, support, operating system and hardware compatibility.

But the most compelling reason is that FMP 6 and earlier is just nowhere near as cool as FMP 8.5 and FMP 9.0. I don't see the need to suffer through FMP 6 as a right-of-passage to becoming a good developer.

[comment]

I don't disagree with any of that. Still, it's a very long way from dismissing "anybody doing active development work in FMP 6". Anybody? If you have version 6, know how to use it, and have a solution that works, I see no reason why you couldn't continue to develop it. Upgrading costs money, and migration from 6 to 7 and above is anything but trivial. I believe all of these aspects need to be considered, in each individual case.

[mr_vodka]

I agree. Furthermore, there are still many companies out there that are still on FM6 and are "afraid" to migrate to 7 without paying for a developer. Others are just content with FM6...

That being said, older versions such as 4 and earlier really should be upgraded to at least 6. IMHO the threshold is FM 5 or 6 for at least me.

[Vaughan]

I still support a company's solution that was written in FMP 6. They don't want to spring for the money to upgrade it. Instead I go in once every few months and delete records because the files hit the 2GB limit and crash.

There is nothing more inevitable than the time when new hardware or software won't run FMP 6 any more. It's coming soon. And as every year goes by it gets harder to find somebody with the skills to migrate such a solution.

I'm not one for advocating upgrades for their own sake (I waited-out 7.0, but 8.0 was good and 8.5 a necessity) but there comes a time when NOT upgrading becomes a significant risk.

[anewc2]

You know, I could have sworn I checked that. But I had not. And it seems to have fixed it. Thanks.

[anewc2]

I would love to upgrade. The question is finding the budget in our small non-profit. FileMaker is conspicuously absent from TechSoup. Also, it will be time taken away from something else to redesign the files.

Amos