I usually use Set Field[] within finds. But sometimes, if I know all my requests are static, I would like to enter them into a find request. In a more complex series of requests, the order of the items can make a big difference in the results because the find request is NOT like a calculation (which short-circuits). It acts more like conditional formatting and keeps evaluating.

If there are many items in the find request and I want to add an item to the top, I cannot. All new requests only add to the end. As it is, if I later want to add a step above, I have to delete all the existing steps, add the new one, and re-add them all again. Please, FileMaker, make find requests moveable like we can do with script steps.

An example of why order matters:

If I want to omit ALL records with Dept = "IS" in a complex find, I can't have that listed first. FM will certainly omit them. But the next line may say FIND Category = "Prepared" (but I don't want Dept = "IS"). I cannot specify not equal and there are 20 Categories. If I reverse that order, ie, list Category = "Prepared" and then Dept = "IS" OMIT, I can get exactly what I want easily because the omit will happen after the find. So I have several finds followed by omits and now want to add another find at the beginning. STUCK.

Of course I can go back to Set Field[] and use Constrain[] and Extend[] but that's not the point. Find Requests should be moveable. :wink2:

Also, while I'm picking on Find Requests ...

If I store my requests within Perform Find[ Restore ], why in heavens can't I see the results placed in the fields when debugging? Enter Find Mode [ Restore ] shows what is inserted; Set Field [ ] shows what is inserted ... but not Perform Find [ Restore ] and it bothers me.

// END RANT

Sub-Rant: FM? At least let us copy the puppies (as we can script steps) if we can't move the find requests up or down!

Edited October 22, 200817 yr by Guest
Added sub-rant

If I understand your problem correctly ... could it perhaps be solved this way?

The issue is that processing tasks follows a sequence that make DeMorgan'ing a complex statement not quite following the rules of parantesis (the associative rules from algebra)

I have often struggled with this issue until the arrival of the unequal relations type and custom functions arrived with fm7 for getting non colliding items shown in a portal for a given timespan, instead of entering the item in the contract to get warned off too late when the record were commited.

However did I get challenged by the issue again, thinking that some of the newer features in scripting might make change the discourse.

Here's what I came up with... using a set of Brian Dunnings sample data for testing:

http://www.briandunning.com/sample-data/

--sd

Demorgan.zip

Oh Soren, thank you for responding. Unfortunately, I can't open your file. It begins with ._ which Windows won't recognize. But even if I remove those characters, FileMaker says it isn't a valid file.

In truth, I'm not looking for an 'answer' but rather expressing dissatisfaction with Find Request's inability to allow easy modification. And I ended up having to go to using Set Field[] on this more complex find because the User (at last minute) said they wanted to include date range (which meant adding globals). I suppose I could have tweaked it in other ways but overall, Set Field[] makes more sense unless it is very very simple one- or two-liners.

Even though I didn't understand one word of what you said, I am very hopeful that the file will show me what you are getting at and I am nonetheless very interested! Please attach the file again!! :laugh2:

Edited October 23, 200817 yr by Guest
Corrected typo

Never mind - I got it open. I was trying to open the version in the Mac folder. DOH!

I just zipped another one on WinXP with the _MacOx things removed!

--sd

Demorgan.zip

I wanted to respond on your demo file, Søren, since you were so nice to present it to me. I've been playing with it off and on and I see many possibilities with it; in fact, it has spurred other ideas for me. But one thing strikes me strange, so I appreciate it if you clarify for me ...

You build your find by pre-filling each field (into multiple find requests) with * which finds any records with data in that field. It seems you are expecting to find all records - at least we hope so because you only modify the request build and constrain after that. Wouldn't a record with a blank field be missed?

Something feels not quite right and, unfortunately, I haven't had the time to test it and won't for another week. If a User specifically changes a field's find request to = (for blank) then I think it might work but what if a User doesn't remember to blank those blank fields?

Ha ha ... blank those blankity-blank fields ... sounds like I'm cursing like Snoopy the Dog! But I hope you see what I mean. I am probably wrong; I frequently am. And I still think the idea is very good!

LaRetta

Wouldn't a record with a blank field be missed

Strictly speaking isn't it something searches necessary handles correctly in any tool you might encounter ... hence the need for validations in a broader sense.

http://www.databasejournal.com/features/mssql/article.php/3399931/Working-With-Columns-That-Contain-Null-Values.htm

http://en.wikipedia.org/wiki/Sql_null

But you're right I haven't tested what my first constrain does to null values ... what I saw with Dunnings data was that an arbitrary found set were unaffected as long each field kept a value issuing a Show All Records between the two part doesn't help much, but other measures exist to keep a found set and recall it ... my guess is that this method leaves the previous request set intact. So it would relieve us from the uncertain feeling:

http://www.sumware.net/robfm/savingfoundsets.php

...should I implement the correction or would do it yourself? I'm a bit busy the next few days!

--sd