Hi all-
I am having some really bizarre behavior with some dynamic value lists
i have set up. I'm looking at a series of "Option" records in a
portal, and when I set the option(from a drop down list) in one, the
available options in the next should change. Here's the thing, the
next Option record down will show nothing in the value list, unless I
close and re-open the file or go into the Relationship Graph, open the
relationship in question, do nothing, and close it.

Isn't that bizarre? What gets updated when the relationship is simply
viewed? Anyone with any in-depth knowledge of FileMaker who could
shine a little light on this bizarre behavior would be immensely
appreciated.

Thanks guys,
Nate

Also, the value list will update if I open the Define Database dialog
and select ANY field in the corresponding record. I don't have to do
anything, just select, open and close and the value list will change
correctly.

This is completely destroying my brain, someone must know what I'm
talking about here.

Nate

If your value list depends on a calculated field try to switch on the
tickbox in the calculation options next to: don't store calculation results

Ursus

"NScheffey" <NScheffey (AT) gmail (DOT) com> schreef in bericht
news:1170186102.872917.220630 (AT) j27g2000cwj (DOT) googlegroups.com...

Thank you so much for replying Ursus, I was starting to think everyone
was disregarding me as a loon. Yes, the relationship that my value
list is based on depends on a calculated key. However, since that
calculation references a related value, it can't by definition be
stored.

This problem seems really strange to me. I can see the calculated
match key, I can visually confirm that it matches the keys on the
records it is supposed to relate to, however the relationship does not
work. GTRR doesn't work, the value list is empty, etc. But then if I
close and open the file, or go into the Define Database dialog and
open any field in ANY table, when I return the relationship works.

Ahhhhhhhhhhh!

Nate

In article <1170189444.583329.305880 (AT) k78g2000cwa (DOT) googlegroups.com>,
"NScheffey" <NScheffey (AT) gmail (DOT) com> wrote:

It might be the calculated match field that is the problem. I've had
trouble using calculation fields for match fields. The solution I found
is to make the match field a text or number filed, and have its value
set by calculation.

--
For email, change <fake> to <earthlink>
Bill Collins

Bill, thanks for the reply. Hmmmmm, very interesting. I am starting to
be suspicious of calculated match keys as well. So you are saying the
match key is set by auto-entry, or by a script step, or something? In
my situation, the key is set to the value of a field in another
record, depending on whether another field is set to Yes or No. I'm
not sure how I would set it by calculation, or when.

Nate

I agree with Bill. I have never had any luck using calculated fields in
relational references. As a matter of fact I shy away from using calculated
fields unless absolutely necessary. Not only have I seen the glitch you are
experiencing but they can also slow down things significantly.

I tend to use scripts to do the calculation then store the result in a text
(number, date, time) field.

Steve


"Bill" <bbcollins (AT) fake (DOT) net> wrote

Thank you all for your help, I think basing this relationship on a
calc field just isn't going to work.Oh well, I will figure something
out.
Much appreciated,
Nate

On Jan 30, 5:44 pm, "GSP@DCS" <i... (AT) dcs (DOT) com> wrote:

Well I think I figured out the problem. Gotta "Flush cached join
results" after modifying match keys, using the Refresh Windows script
step. So that means my users are going to have to select an option,
press a button, select the next, press a button, etc. That kind of
sucks. Hopefully 9 will have that event trigger functionality.
Oh well,
Nate



On Jan 31, 10:10 am, "NScheffey" <NSchef... (AT) gmail (DOT) com> wrote: