In the case of:

set error capture on

Enter Find Mode

set field x,y

Perform Find

Enter Find Mode

Set field a,b

Constrain Found Set

What is the proper behavior if the first Find results in zero records? Shouldn't the Constrain then also find zero records, since logically anything constraining zero is zero?

I'm finding a case where it does not work this way. Instead the second constrain is finding records as if it were starting from All records.

Bug or feature? Did this change in FM 7 or 8 or did I just never encounter this particular data pattern before?

I tested this with 7.0v3 and 8.5v1 and both behave as expected - the result is an empty found set.

I'm finding a case where it does not work this way. Instead the second constrain is finding records as if it were starting from All records.

Set Error Capture[on]

Enter Find Mode[]

Set Field x,y

Perform Find

Will not (to my knowledge) return a zero found set if it finds no records... It will return whatever found set you were viewing before.

... Capture for an error instead.

Set Error Capture[on]

Enter Find Mode[]

Set Field x,y

Perform Find

If[ Get(LastError) <> 0 ]

Omit Records [ Get(FoundCount) ]

Else

Constrain Here.

End If

Edited May 4, 200718 yr by Guest

Will not (to my knowledge) return a zero found set if it finds no records... It will return whatever found set you were viewing before.

I think that was true for early versions of 7. I don't think it's true now.

Out of interest I just did a find on non existent data and monitored the Get(foundCount) function through the data viewer.

When the 'no records exist...' message came up it didn't appear to have changed from the original figure of 11 but when I opted to modify the find it changed to 1

I don't know what that confirms...if anything

Phil

Update -- it turns out my actual script was something like this:

set error capture on

Enter Find Mode

set field x,y

Perform Find

if Get(FoundCount) = 0

  DoScript (output a log message on another layout)

end if

Enter Find Mode

Set field a,b

Constrain Found Set

if Get(FoundCount) = 0

  Exit Script

end if

It looks like what was happening is that the second Get(FoundCount) was not evaluating to zero records, and the script was not exiting properly.    I'm suspecting that something about the DoScript call (which goes to another window, creates a new record, then returns to the original window) was screwing up the Get(FoundCount) results?   I'm only seeing this on a machine running 8v3, whereas my development machine (8.5v1) is not showing it when I step through the script.   



In any case, I worked around it by the following:

  Enter Find Mode

  Set field X,Y

  Perform Find

  SetVariable $N = Get(FoundCount)

  ... do some stuff...

  If ($N = 0)

    exit script

  end if

This seems to have fixed the problem, though I'm not fully happy with not understanding what's going on here...

Yesterday, I called FM tech support regarding an unexpected result using "constrain found set". It's a bug in the program. They referred it to the programmers. I use 8.5 Advanced. I don't know if the bug affects other versions of FileMaker.

The Get( FoundCount ) function may have been counting the number of find requests while in Find mode.

In my situation, Get(FoundCount) was returning 18,000 and change records, in a table that only had 12,000 records, so obviously not returning the # of find requests. In my case, however, I had an intervening script which went to another table and created a record, then returned to the original window. It almost is behaving like something wasn't cached properly when it returned to the original window and had zero records?

It sounds like the focus has changed as a result of the subscript. I suspect if you forced the focus to return to the proper table and proper window, your get(foundcount) would show what you were expecting.

Something like:

set error capture on

Enter Find Mode

set field x,y

Perform Find

if Get(FoundCount) = 0

DoScript (output a log message on another layout)

end if

Select Window [ Whatever Window ]

Go to layout [ Whatever Layout ]

Enter Find Mode

Set field a,b

Constrain Found Set

if Get(FoundCount) = 0

Exit Script

end if

Edited May 12, 200718 yr by Guest

It sounds like the focus has changed as a result of the subscript. I suspect if you forced the focus to return to the proper table and proper window, your get(foundcount) would show what you were expecting.

Yes, it seems like this was happening. However, those two script steps (select window and select layout) are already present (in the subscript).

And 99% of the time, this was working w/o problem. It was just when the first find resulted in zero records that I saw it, and even then only when running normally, not when stepping through in the debugger. Weird.

There are sometimes If[] conditions in subscripts that causes them to exit, that's why I say to have the focus reset in the main script. It's hard to say for sure without seeing the subscript.

Edited May 15, 200718 yr by Guest

Hmm -- I have a theory. The subscript is a logging script which takes a parameter, parses it, and adds a new record to a log table, scrolls to the last record and refreshes the window. It remembers the prior window name in a global, and then goes back to that window at the end.

However, I just realized a possible error -- if this script is called from Find mode (rather than Browse mode) perhaps the save/restore window step is broken, since it's saving the window name in a find request, rather than actually setting the global? Here's the script:

Set Field (globals::LastWIndowName; Get(WindowName))

Freeze Window

Select Window ("LogWindow")

Go to layout ("Log")

Enter Browse Mode

Show hide status area[hide]

new record request

Set field (Log::Message; Get(ScriptParameter))

Set field (log::User; Get(AccountName))

Commit Records/Requests [skip validation;no dialog]

Scroll Window [end]

REfresh window

Select window [name: Globals::LastWindowName]

My theory is that if this script is called in Find mode, the first line will fail, which means the last line will also fail. Thus, the calling script will not be back to the window/layout where it started, causing all sorts of problems.

I think the solution would be to do a "Enter Browse Mode" as the first step?

Edited May 17, 200718 yr by Guest
typos

If my theory is correct, this would lead to some warnings about using subscripts:

First, it's generally better / safer to use script variables (either $var or $$var) instead of globals. Variables always behave the same, whereas globals behave differently depending on whether you are in Browse or Find mode.

Second, don't assume anything about the status when your subscript starts. If the script needs to be in Browse mode, then you better set Browse mode.

Third, be careful when using "Set error capture [ON]". Remember to turn it OFF appropriately. With it set ON, scripts that would normally exit due to error will keep running along, perhaps doing damage.

I'm sure other lessons apply?