Constrain bug in Filemaker 7

[ctz243]

There is a serious bug in Filemaker 7's constrain script step.

In FM6, if you did a find and then constrained that found set, you'd get fewer records. If the constraint resulted in zero found records, the result would be a found set containing zero records. Any further contrains would always result in zero records.

Now in FM7, if a constraint finds zero records, it returns a 401 error BUT the resulting found set IGNORES the contstraint totally and actually contains all the records that were in the found set prior to the constraint!!

This must be a bug! It is ridiculous!

'Constrain' is no longer constrain at all, it is constrain (so long as the result is not zero). Now, if you want to sequentially constrain a find, you must do the find, test for error 401, then constrain, then test for 401, then constrain, then test 401.... if you get the 401 error it's time to leave knowing there are no records that meet this criteria. Otherwise you'll get ridiculous results.

Whereas in FM6, you could just go find, constrain, constrain, constrain, and the output would be zero found at all times.

As an example of how bad this is, lets say a Find gets 1000 records, constraint 1 gets down to 200, and constraint 3 results in zero . In FM7, the resulting found set will contain 200 records (not zero)! Worse still if you had, after constraint 3, a constraint 4, you might get a result of say 50 records (depending on how constraint 4 acts on the 200 that slipped through). Note that the 'correct' answer, and the way Filemaker 6 did it, is to result in ZERO records in this situation.

Could someone please verify this.

It seems to be a definite bug, and will cause scripts in FM6 to fail if they use serial constraints. The only workaround is to test for 401 errors at every single 'constrain' point.

[Michael Myett]

It seems to me that the results in ver 6 don't make sense. What good is a found set that doesn't contain any records?

This find and the constrain found set should be run from a script with your own error trapping built in. If no records are found with the constrain, bring up a dialog giving your users the choice to keep the last found set, show all, or run a new search, for example.

[ctz243]

Surely the final output after a series of constrains should be correct? What good is a found set that *should* contain no records but actually contains hundreds?

I have now put error trapping for 401 after each single constraint, but this means that now the code is four times as long and much more difficult to read than before just to achieve the same result.

How can it not be a bug for a series of constraints that *should* result in zero records to actually result in a found set containing hundreds? This is precisely what happens in FM7 - but not, as I explained, in any previous version. You can check every single constraint logically and the output should be zero, but in FM7 it won't be. The documentation says each serial constraint acts as an AND step, narrowing the search. In actuality, it does not.

Here is a tiny file. Try and you'll see what I mean.

chris

example.zip

[ctz243]

Sorry the previous file may have been locked. This one opens with guest having full access. It is an 8k zip archive.

WIth a few button clicks you can see the (incorrect?) effect of serial constrains after a find.

I'd be grateful for feedback on this.

Chris.

ConstrainProblem.zip

[Fenton]

There is a new behavior in 7, which is that Found sets are more or less "preserved." Actions which previously produced a found count of zero now revert to whatever the found count was previously (there may be more to it than that, but that's my simple take on how it works).

Yes, it's more work I suppose. But looking at it from the casual user's point of view, one can see the logic. You do a Find. You do a Constrain. Oops, the criteria you used was not present. FileMaker preserved your previous Find, so, in case you made a mistake you don't have to start over.

Of course, the opposite logic could be used, that you could now be misled into thinking that all the previous records must have matched your Constrain, because they're all still there. Both make some kind of sense.

In some ways I prefer the old behavior, as it cannot mislead. You enter a criteria that cannot be found, you get nothing. On the other hand, once you know how it works, you can use Error Capture to display messages and/or fork appropriately. And you don't have to worry about preserving the previous found set (which would actually be a lot more work). In the long run the new behavior will result in better Find scripts.

This also applies to Go To Related Record [show, "No matches relationship"]. This is why it's important to always check:

If [ not IsEmpty (relationship::field with data) ]

before going. That's just good programming.

As Michael said, what good is a zero found count to the user? You've got to do something. Now you have the option of explicitly showing all records, or, by default, leaving them in their former found set.

[ctz243]

I'm grateful for your response, but perhaps I didn't make the problem clear enough.

First, 'constrain' is supposed to perform a logical 'AND'. What good is a constraint that *should* return a found count of zero if instead it returns hundreds of records!

In the old way, it was still possible to trap the error because 401's were reported whenever the found count was zero. So you could do whatever you liked. But now, one 401 error is reported, but the found count immediately becomes positive, so checking for a found count of zero will fail.

So instead of simple code like this:

find

constrain

constrain

if (found count is zero)

---tell the user no records were found

else

---do something else, ie print the outstanding accounts for this client

end

the new way has to be

find

if error is not 401

constrain

if error is not 401

constrain

end if

end if

if (error is 401)

tell user none were found (found count will NOT be correct)

else

some were found (foundcount will be correct)

end if

As you can see, the new code requirements are much more tedious!

As regards your question, what good is a found count of zero... imagine you want a button to print all unpaid accounts for a particular date range, and you want a simple means to constrain the output to either all clients or just some particular clients, either to use different stationery or for some other reason. It would be a simple matter to constrain the original find by client. If the found count was zero, no accounts need printing. It doesn't matter to the user if there are none because there are none outstanding, or what the reason is. They are happy to know that the end result of the search was a count of zero. There is nothing wrong with that.

But in Filemaker 7, the logical flaw is real. The manual says 'constrain' does a logical 'AND'. Zero records is a perfectly valid outcome for an AND search! In fact, FileMaker 7 only does an AND search provided that the result is non-zero; if the result is zero, it does an OR search and returns a positive number. Anyone who understands set theory knows this is an error.

Imagine I have 1000 people, and 100 have blue eyes, and 50 are old. I want to find how many old ones have blue eyes. If I went, find blue eyes, constrain to old, I'd expect the found count to be 50. Let's say only one of the 100 with blue eyes were old. Then I'd expect a found count of 1. This is true both in FileMaker 6 and FM7. But, let's say NONE of the 100 with blue eyes were old. Then I'd expect, and set theory as well as logical AND searches require, that the output would be ZERO records found. This is what happens in Filemaker 6. In FileMaker 7, the output is, wait for it, 100 records!

Go figure.

Sure, if you trap every find with a 401 then you'll be OK; you could do this before also if you wanted. But the underlying logic is faulty, the found count is simply incorrect, and code that used to work properly and logically now fails.

This is a really fundamental error and I am sure it is a bug rather than a deliberate action.

chris.

[ctz243]

I did another test - see the attached SMALL file!

In this example, with Error Capture on, a scripted find followed by a constrain results in an incorrect (non-zero) found count, where the correct response should be a zero count.

Using the 'Perform Find' script step with identical find criteria a correct (zero) found count results.

The bug is in the Constrain Find command. It does not work!

ct

ConstrainProblem2.zip

[Michael Myett]

Some are going to see this as a bug, others as an enhancement.

If you would like to return the user to the previous found set in the event of a null constrain result, it can be done without rescripting the previous find request. You only need to provide the user with a message "no results returned, returning you to previous results".

I still believe this to be a deliberate change by FileMaker.

[ctz243]

Mike, I could do all this in FM6 and I know exactly how to provide users with messages whenever I want.

You don't seem to appreciate that if you do sequential finds manually, or make one 'combined' find, or do a find followed by one or more constrain found set finds, that the FileMaker manuals say that ALL of them do EXACTLY the same thing, ie that they perform AND searches. This is specifically explained for constrains in the help menu.

This means that progressively tighter restrictions must result in fewer records, and that if none match the correct output should be zero.

In all of these ways of doing things, a 401 error is the outcome of a null found set - this behaviour is exactly the same in FileMaker 7 as it was in FileMaker 6. All three techniques also returned a zero found count - correctly - when a search that should result in a zero found count was done. This is consistent with their descriptions in the manuals.

Now, in FileMaker 7, there are no changes to the description of how these steps work in the manual or the help file. All three approaches still return 401 errors the same way. But now, and only in FileMaker 7, the constrain technique - unlike all the others - returns a incorrect non-zero counts when the correct answer is zero.

This is *not* likely to be deliberate. If FileMaker had deliberately intended to change the way a Find:Constrain Records script step was working, when moving from FM6 to FM7, they would have explained the difference somewhere.

I fail to see how the same feature, that has been around since at least FM5 and worked the same way then, but now is broken, can be anything other than a bug.

We'll find out, however, as the bugs are slowly ironed out. There are bugs in sliding and in dragging parts to new layouts. In time they will be found and fixed. Then we know who was right in this discussion....

[Michael Myett]

I apppreciate your viewpoint regarding this issue, just disagree with it.

I don't think any of us want our end users looking at a null found set wondering where to go next. Since, both sets of results can be equally confusing to the end user, good error trapping is important, in either case, ensuring the user sees the same result with instructions on how to proceed.

As long as we, as developers, know how FileMaker handles a certain situation, can then provide the user with what they need to see in the end result. I just believe developing is a little easier with the current configuration. For example, if the constrained find = 0, one of the options you would certaily offer your users is to return to the previous set of results. This can now be done with a simple "Exit Script".

Whether it's a bug or a design change, the issue can certainly be dealt with easily enough, on the developer level.

Best regards,

[ESpringer]

Though ctz243 is certainly right that FileMaker goofs in its documentation by failing to say how cumulative scripted constrains behave different from all-at-once scripted AND finds, that's a separate question from whether this behavior is a useful change. Two thoughts:

(1) It's rare that a script would use a compounded sequence of constraints rather than one search for all-30day-outstanding-accounts-for-people-with-red-hair, or whatever. (Correct me if I'm wrong?) A script anticipates the full set of criteria in advance. You should only have to trap once, generally.

(2) The other thought is that ctz243 should at least acknowledge that there's a good motive for the new behavior (even if documentation is slightly off): outside of scripted contexts, it happens often that a user is slowly narrowing a search (say, through a bibliographic database) and recognizing the need for constraints on the fly, narrowing after realizing that stray data is in the way. Now if one has already performed several constrains, and then does something stupid like looking through legal articles... on inheritance laws..., U.S. laws only..., which also mention taxes or exemptions..., last two years' only..., available locally only..., but excluding any reference to a "will"... (not remembering that "will" is a common English word... oops.) Well, you know the string of expletives that will follow from having the repeat the entire narrowing process, criterion by criterion. Bounce-back is a live user's best friend.

[Oldfogey]

Michael, you are too easygoing. It's a bug. They should fix it.

I never use Error 401 for two reasons. First, I can never remember the number. Second, there could be some other error that fouls up the Find.

I use Error Capture On and Status(CurrentFoundCount).

It is just ludicrous to suggest that it is OK for a Find to return the wrong number of records.

[Michael Myett]

Okay, lets call it a bug. I still feel an obligation as a developer to make sure my end users are never faced with a zero found set, so if FileMaker acknowledges this as a bug, and I have a gut feeling they won't, I will still error trap for "401".

Our job as developers is to provide an understandable, user friendly interface for data storage and manipulation for the people who pay us.

So I guess what I am really saying is I'm willing to work with this minor problem. In the past, there have been bugs not so easy to circumvent.

Best regards,