Strange behaving relationship

[anders_t]

Hi!

I have set up a one-to-many relationship that works as expected. However, when my client tries to click on an entry in the portal, he's sometimes (not always!) directed to another entry!

I have tried to reproduce this weird behaviour on various computers while logged in as my client, but every time the relationship just works!

I'm starting to suspect that it's his FileMaker copy (or his computer?!) that's causing it.

Any ideas, or is there something that I've missed?!

regards

[bcooney]

However, when my client tries to click on an entry in the portal, he's sometimes (not always!) directed to another entry!

It's not clear to me what you mean by this. What is the expected behavior? I could guess that you have a button on the portal row that does a gtrr.

[anders_t]

I could guess that you have a button on the portal row that does a gtrr.

Erm, yes, sorry about not being clear enough. :

Yes, there's a button that's supposed to do a gtrr!

[Søren Dyhr]

My guess is that the script attached to the button, has a "Commit Record" step providing the loss of focus!

--sd

[anders_t]

My guess is that the script attached to the button, has a "Commit Record" step providing the loss of focus!

--sd

No, there's no "Commit Record" involved. And as I said, it "just works" every time for me, but just sometimes for my client...

[IdealData]

Check your client's version of FMP. GTRR changed after v7.

[anders_t]

Client's version is version 9.0v3.

[bcooney]

Ok, so we've ruled out that you're losing focus with an errant commit records step. So, you do go to the other table, it's not as if the gtrr fails? You're just gtrr the incorrect record? Possible data issue--duplicate keys?

[anders_t]

The only time the GTRR fails is when my client is logged in on his own computer. When using his account on another computer, it works as expected (and I've clicked through all of the related records).

He's using FileMaker 9.0v3 on an OS X 10.4.10 system.

[bcooney]

My definition of gtrr failing, is that you do not go to another record AT ALL (ie, the relationship is not valid). So, is it failing or is he going to the WRONG record?

I'm starting to suspect that it's his FileMaker copy (or his computer?!) that's causing it.

Did you investigate this?

Edited October 26, 2008 by Guest

[Vaughan]

Client's version is version 9.0v3.

There was a documented change of behaviour for relationships in FMP 9.0. It's got something to do with empty fields no longer matching related records. Details are in the FMP 9.0 REad Me file:

In the previous versions of FileMaker, some predicates in a relationship would be ignored if they had an empty value. This could result in finding records which don’t match the relationship criteria, even finding all records in the related table. Predicates based on empty values will no longer match to any other records. Any databases which depended on the old behavior will need to be modified to use a different relational design. This change was made to match standard relational behavior in SQL databases.

This is probably the problem.

[anders_t]

I am using the same version of FileMaker Pro as my client. There are a total of 50+ related records in this particular relationship, and when I do a GTRR using my account on any computer, it works every time.

When my client tries to do the same logged in on his computer, it sometimes work.

An exact copy of my client's account worked flawlessly on several other computers I tried out this weekend.

I have yet to try out a few different approaches on my client's computer, but will hopefully be able to do this today.

[Søren Dyhr]

What I would like to know is how both key values are established, reluctant changes in calculated keys or dependencies on global values.

Next issue I can think of is type mismatches on the sides of the relation.

Perhaps a more succinct description of what the relations definition is supposed to handle could lead us in direction of the felt issue? In other words the next to proverbial "...context and purpose" since hardly anyone can guess anything when a thingy "...doesn't work" given abstractions only!

Too many tools are being blamed for being inadequate in performance, when the data context it's supposed to deal with deliberately is ignored. Premises chosen arbitrarily by whims, are usually used to slander, make excuses and win hidden agendas and has very little to do with scientific examination.

--sd

[bcooney]

Overnight, I came to the same conclusion as Soren, but with much less eloquence.

Can you please tell us the table names and fields that are used in the relationship and exactly how the keys (both foreign and primary) are generated. It is possible that you are calculating keys, perhaps dependent on a global, so that each user's experience is different. Otherwise, have you confirmed that it's only one workstation--and that there is not a duplicate copy of the file on this workstation.

[comment]

and that there is not a duplicate copy of the file on this workstation.

That (combined with file references) would be my prime suspect, given the description.