Logical AND with multi-line key

[comment]

you can't do a find with Attribute = A2 and Attribute = A3 in one request.

Yes, you can:

all you really need to do is dump the selected attributes into the searched field, in a single request

But "=" can lead to false result like Red Bull

I suppose that could be handled too, but let's not make this about find techniques.

[genevieve charbon]

In reply to:

you can't do a find with Attribute = A2 and Attribute = A3 in one request.

Yes, you can:

comment Said:

all you really need to do is dump the selected attributes into the searched field, in a single request

I'm sorry but I don't see how, really.

I tried it by placing several time the same attribute field entering find mode with different criteria in them, and this don't work (it seems so, but doesn't only consider the last entry)

Use the attached file and please find in one go, Product A and B and not C using A1 and A3 as attribute search criteria

The table is like this

Product A A1

Product A A2

Product A A3

Product B A3

Product B A5

Product B A6

Product B A1

Product C A3

PrtoductAttributes.zip

[genevieve charbon]

You said previously

attribute = "Attribute2" AND attribute = "Attribute3"

which is a contradiction

So finding all products that have a1 AND a3 in find would conflict with what you said just above

I'm really puzzled, I really can't see how it would be possible with one find request ! Please show me using the file posted just above

[comment]

Sorry, I don't know why I keep forgetting you're doing this in a join table. You're right, you need a series of constrains.

IIRC, in my tests, filtering GTRR results was also faster than finding - but the difference was not dramatic enough to warrant the added complexity. Of course, a lot depends on the actual data and usage.

[genevieve charbon]

Thanks, I was starting to get crazy !

I really urge people with slow script to look to replace finds with GTRR because I had that experience where one script I made took hours to complete and then took less than 5 minutes with just replacing the related finds with GTRR

So I think that thread is closed now, an hope it will help some

[Søren Dyhr]

I really urge people with slow script to look to replace finds with GTRR

...And I really urge people when ever scripting gets lengthy, to investigate if the relational structure is somewhat inadequate in some respect!

If datamining is the task, don't expect filemaker to be "Jack Of All Trades" ... more obvious tools exists.

--sd

[comment]

investigate if the relational structure is somewhat inadequate

I am curious if you have any alternatives for what is after all a classic many-to-many with a join table.

[Søren Dyhr]

Yes here, it is - but there is danger is to compare apples and oranges.

Another thought was if Agnès approach could have bearings here:

http://www.fmforums.com/forum/showpost.php?post/289907/

--sd

[Søren Dyhr]

Regarding the GOTOvs ... template!

I don't think your test is relevant to the issue at hand.

There is more errors to it, there is absolutely no need to issue a "Show All Records" in the scripts loop, since the arrival of Constrain... have Perform Find no need for it any more - this dates back to fm6!

--sd

[Søren Dyhr]

Meanwhile did it occur to me when looking at the template ... the objective here is something in the vicinity of locating the invoices where we have sold the items {1,3,7}

Now there have mentioning of the user makes his/her selection in a check-boxed field, but unfortunately can't such a field have a scrollbar attached when formatted as checkbox, so more trickery must be applied, here comes a cartesian portal in handy, with Jeff Almquists method applied.

--sd

AndedJoin.zip

[bruceR]

Here is another way to manage the relation; by using scripts and custom functions on the "left" side of the relation.

AndedJoin.fp7.zip