Odd behavior of button/script

[Steverino]

I have a list view, and one of the fields ("title") is a button that will take you to a detailed record. Someone in my company complains that sometimes when he clicks on the title, it takes him to a completely different record (and he insists he's clicking in the right place, and this has been verified by others here). Does anyone know what might cause this glitch?

[DanBrill]

Is it only on his machine? Weird....

But, I'm guessing that the button is set for "go to related record"

So I'd start by looking at the relationship to make sure that it's doing what you think it should be doing.

Dan

[Ugo DI LUCA]

Dan is right, you could look at the relationship if you are triggering a Go to related records script or to other relationships used in that script.

I'm quite sure it is related to the "relationship" definitions and the keys used. Let me share with you one similar bad experience that I dealt with and lead to terrible purchase mistakes.

Case Importing a Product Code from a +75,000 records database to a Line Item

2 ways the code was entered :

- the easiest one was to enter the code if the user knew it No Problem occured.

- Another method was to filter the Product database using a set of three conditional value lists to reduce the choice to the desired article.

First value list was for the Vendor Name,

second value used the newly created relationship Vendor Name::Vendor Name to display a list of all collections.

Third value-list used the newly created relationship VendorName&Collection::VendorName&Collection to display a list of all Product Designation for this Collection and Vendor Name.

When choosen, the desired nProduct Code was imported through a lookup to a temp_nProductcode and a button next to the ProductCode was set to import the temp_Productcode to the nProductCode.

But some bad codes were imported (so bad prices... ....bad purchases...

It took me a week to understand this simple mess-up. While the relationships for the value-list were OK, using concanated calc fields, the lookup used another simple relationship : ProductDesignation::ProductDesignation.

As you understand, some products had the same Product designation (even with different Vendors and collections ).

[SteveB]

How about something as simple as one script assigned to the button, an another assigned to the label on the button?

[Steverino]

It isn't even a relationship (I could understand that). It simply takes him to a different layout (not list view).

[Steverino]

Steveinvegas -- that makes sense, but it's not the case (I checked).

[Vaughan]

What version and patch FMP? I solved a weird case yesterday (access denied for all layouts) by upgrading the user from 5.5v1 to 5.5v2.

[Steverino]

It's 5.0.0.114.

[Vaughan]

FMP versions are usually in the form XvY where X is the version number and Y is the patch level. For instance, 5.0v1 or 5.5v2 or 6.0v4.

The version information you posted looks more like it's from a Microsoft product like IE. Is the user browsing the records with Internet Explorer using Instant Web Publishing?