Exact find using a value list

[Unable]

"The "-lop=or" certainly does have a few variants to the result!"

Yes, that was what I was observing. Thanks for your confirmation. I did not think my app. was corrupted.

The problem with the use of "quote marks" such as you have suggested arises in regards to Jerry's needs (08/22/03 08:43 PM), "The categories are in a drop down list. "

Aside from the client being instructed to enclose their data string manually with quote marks (which they cannot do with a drop down), I know of no way to accomplish such wrapping of a data string. Of course one could code the quotes in when constructing the valuelist. In which case one could just as easily use a joining underline or the option-space to construct the list in FileMaker. I suppose selecting one of these choices would depend on the desired aesthetic of the drop down (does one want to see "fishing books", fishing_books or fishing books on the browser).

What is important here to understand is that when a developer uses the -LOP value or, a new request will be made for each individual word separated by a space from each other word in the field (fishing books for dummies would generate four requests; fishing books for dummies and geniuses would generate six requests), unless the developer takes some action such as has been suggested.

[Garry Claridge]

Re: in regards to Jerry's needs

Jerry needed "-lop=and" (the default) so that he could add more criteria to the search. That is why he had to look at ways of not including the "category" in the search when none was selected.

Some interesting results. I will have to remember these.

Well done. All the best.

Garry

[Unable]

Interesting how one interprets things.

08/22/03 08:15 AM

"...can find item by ID num, or by name. But there also is a value list that shows catagories. I want to be able to select a catagory from the VL and get all the items in that catagory. The problem is the catagory names overlap. "

That category names overlap indicates to me the need to use a field contents match. And there are three fields involved.

08/22/03 01:21 PM

"I am looking for a hard coded 'exact match' for some reason that I can't fathom, FMI decided that that option need not be included in the alowed -op variables. (equals is not the same as exact match..."

According to the CDMLRdb under the tag operator we find (Short) eq (Long) equals (FileMaker Pro Equivalent Operator) =word, and in the db file status bar under symbols = Equal Match. So contrary to what Jerry interpreted, eq performs an equal match. Had Jerry studied the demonstration to which I directed him, and had he followed the instructions therein, he would have discovered that when he selectd the -op equal and entered Sandy, the string which was entered by the CDML into the search field read =Sandy - the code of an exact match. Like I say, it's interesting how one interprets things.

It was clear to me that Jerry needed to use the field contents match so that a search on red would not return red dots, which an exact match will do.

08/24/03 07:33 AM

"Can my users have their cake and eat it to? Using your solution how do I handle not selecting a category but selecting another parameter?"

Since the category must use a field contents match, then == is being entered in the search field, even if an item in the category is not being selected. This symbol alone will cause no records to be found and will return an error. For the find to succeed when other find criteria have been selected but not the category, if the default -LOP is used only an error can be returned. Therefore it is imperative that the solution use the -LOP or.

I have posted a demonstration in Sample Files where one can test the CDML -LOP values.

[Garry Claridge]

Re: Since the category must use a field contents match, then == is being entered in the search field, even if an item in the category is not being selected. This symbol alone will cause no records to be found and will return an error.

That is why the <select> is structured to only add a "==" when a data item is selected.

e.g.

<select name="category">

<option value="">Select Item</option>

[FMP-ValueList: category, List=categoryVL]

<option value="==[FMP-ValueListItem]">[FMP-ValueListItem]</option>

[/FMP-ValueList]

</select>

Note that the first <option> has a value of "". Hence no "==" is sent to FM, allowing other fields to be searched on with a "-lop=and".

All the best.

Garry

[Unable]

Hmmm. Thanks. I will check that out. My nose must have been too close to it to see things clearly. I had been concentrating on two word categories through that code, so I did not observe it with no selection made. The field (which I was leaving blank) which was making the entry was from the code you had suggested:

<select name="category==">

<option value="">Select Item</option>

[FMP-ValueList: category, List=categoryVL]

<option value="[FMP-ValueListItem]">[FMP-ValueListItem]</option>

[/FMP-ValueList]

</select>

I should add that I did look at the code as shown through the two browsers' View Source option. And I did notice how the code to which you have just referred is expressed there. And in light of that your observation makes sense.

Like I said, it's interesting how one interprets things. I just had not seen that which you did. Thanks again. And for your other help and input as well.

[Unable]

I reexamined things and have posted a new set of format files for the demonstration reflecting the use of consistent code and which utilizes Garry's observation on the non-entry of "==".

Yeah, it's cool.