Searching from the start of a field: ==puzzled*

john white ifc · May 30, 2002

I want to set up a search for records where a particular field begins with a user-supplied string. For example, if they enter "Canadian" the result should include "Canadian Association of FileMaker Developers" and "Canadians Against Fresh Water" but not the "Association of Canadian FileMaker Developers" or "Too Many Canadians". Of course, in FileMaker the search string is...

     ==Canadian*

in the search field. Naturally, I don't want to require the [color:blue]==color=blue> and [color:blue]*color=blue> characters to appear in the text input box itself (since that exposes the user to a quirky bit of FileMaker search technique). Then I read Keith M. Davie's reference to TechInfo article #104829, which ALMOST solved my problem. The suggestion was:

     <input type="hidden" name="searchfield" value ="==">

This is very cool, indeed -- WC is sees the matching Name= attributes as an instruction to concatenate the Values together. (This might be basic HTML, but I sure was impressed.)

However, my situation requires the addition of the [color:blue]*color=blue> character. The obvious solution was to add another Hidden input afterthe Text input:

but my searches failed. It turned out WC is putting together a search string that looks like this:

== Canadian *

That one little space before the asterisk means that "Canadian Association" shows up in the result, but not "Canadians Against".

I know this is a tiny difference, but it could puzzle a user (one of the Seven Deadly Usability Sins), and I hate to get so close and fail.

Any suggestions?

_____________________________

System:

FileMaker: 5.5v1

Web Companion: 5.5v4

Testing Browser: IE 5.1

Garry Claridge · May 30, 2002

Would 'Begins With' help you?

<input type="hidden" name="-op" value ="bw">

All the best.

Garry

john white ifc · May 30, 2002

I will try it, thanks, but since that's the default search method, I don't see how it'll make a difference.

I think what I'm up against is, when I concatenate the user's search string with hidden text strings of my own before and after, WC inserts spaces between the concatenated strings. That's why I end up with

== Canadian *

instead of

==Canadian*

The first space makes no difference to the result, but the second one does.

I wonder... if I can't change WC's concatenation behaviour -- or finesse it somehow -- I might have to do my own concatenation, with JavaScript. Too bad -- kind of a silly thing for WC to do, dontcha think? Or am I missing something?

Garry Claridge · May 30, 2002

Don't use '=='.

Garry

Keith M. Davie · May 30, 2002

Hi. I read your message just before I went out. So the first thing I did was think about what your problem was and how I was going to experiment.

I have this personal db (thoroughbred horses) which has close to 30,000 records. So when I got back I opened it and did a search of the field dam (text, indexed) for horses with the word beauty in their names. Got 73 of those. Next, directly in the db, I did a search of beauty*. It returned the same 73 records. Finally I did a search of =beauty and it returned the same 73 reocrds. Since no dams are named Beauty, a search of ==beauty found no records.

This is in FMPro 5.0.v3.

Next I wrote four quick format files (default, find, results and error) and set sharing for this db file. Then I experimented.

Using a form action with the code

I was "successful" and returned these same 73 records.

Using a form action with the code

The first result I noticed was that this "wildcard" symbol cause the find operation to be slow and grinding. Next I noticed that the field was populated for the find with beauty * (with a space between)

I was "successful" and returned these same 73 records.

Then, using a form action with the code

I was "successful" and returned these same 73 records.

Examples of names returned: Beauty Sleep, Crawley Beauty [Fr], Gold Beauty and Stick To Beauty.

Finally I used a form action with the code

which returned only 10 records and only those which began with beauty.

I believe this latter form action gave the results such as you are trying to achieve.

Thanks, this was fun.

john white ifc · May 31, 2002

_____________________________

But Garry, I have to use '==' because it's the field-content-match operator, and it's the point of what I'm doing. And it's really not the problem here, as the TechInfo snippet showed. The problem is, I need the perfectly valid FileMaker search expression [color:blue]

==string*

color=blue> but if I apply the technique used in the TechInfo article, WC reads it as [color:blue]

== string *

color=blue> with extra spaces inserted. Those spaces are causing the problem, and that's what I need to work around.

_____________________________

Keith: thanks for doing all the experimenting. Unfortunately, your last example is what I described as being not quite what I'm trying to achieve. Your choice of "Beauty" as your test string hid the tiny but important difference I'm trying to capture, and I guess the test string I gave didn't make it much clearer. Let me try again.

Supposed I'm in your database and I want to find all the records where the horse's begins with the letter b. My result should include Beauty Sleep, B is for Banana and Bedtime for Bonzo, but not Gold Beauty or Mikhael Berezhnikov.

So I sit down at your database and enter ==b* as my search string, and my result is as I expected. Now I do the search online, using the your last form action, and the only horse that comes up is called [color:blue]B is for Bananacolor=blue>

Why? When I go to the database, I see that WC entered this search string:[color:blue]

== b *

color=blue>with the two extra spaces. It's the second space that's making the difference. Seems like the '==' operator is causing FileMaker to read the rest of the expression literally, including the space. It means I get horse's names that begin with the word "B" but not theletter "B".

(Frankly, I don't know why the first space isn't also taken literally, but it isn't.)

_____________________________

So there it is folks, as clear as I can explain it. WC is lets me adjust a user-entered search string by concatenating extra text before and after. That can be useful, except that it also inserts spaces that I didn't ask for, and in certain settings that makes the wrong kind of difference.

It's not the end of the world to have the user search under the simple 'contains' or 'begins with' operators, but as I say, I hate to come so close and then be denied by a tiny little space character.

Keith M. Davie · May 31, 2002

Ok, I see the problem.

Possible solution 1. Use the form action code:

Along with instructions to your clients that they should enter the letter they desire to search upon immediately followed by an asterisk with no space between the two. (e.g. b* not b *)

Possible solution 2. Use two form acitons. One provides the code above. The other is for searching on a string which begins with a particular word (e.g. Canadian) and which uses the form action code:

Garry Claridge · May 31, 2002

Here is a URL to try:

http://139.130.177.9:1154/FMPro?-db=combotest.fp5&-lay=name_list&-format=testname.html&name=bloggs&-find

In the database I have 12 records. You can check the various names with '-findall'

All the best.

Garry

Anatoli · June 1, 2002

Hmm, the link doesn't work.

(Both databases are running without security.)

Keith M. Davie · June 1, 2002

John you have quite the conundrum.

After re-reading the cdml reference I tried:

where (as the client) I submitted b. Interestingly, this entered == b as the search string. The asterisk was either ignored or over-ridden by the double =. No exact match resulted. Same results when the bw and == are reversed.

The code

where (as the client) I submitted b, caused a search upon == b *. This resulted in 2 found records.

I tried:

where (as the client) I entered b*. This caused a search upon == b* *. This resulted in 20 found records.

The earlier suggention of code

where the client enters b*, caused a search upon == b* that results in 1721 found records.

The only other suggestion I can offer is to try some JavaScript to create the entry string. Regrettably I am of no help there.

As to the use of "bw", it seems its only value is when used in conjunction with a hard code of "==" before the actual search criteria, which is the example presented in the cdml reference. When I used the "bw" (without any hard-coded modifiers):

over 3400 records were returned on a submission of b. This included any record in which any word began with b, such as Crawley Beauty. This is as useful as teats on a boar. Consider too that "bw" is the default operator.

In part this is why I recommended the articles for the use of the symbols in lieu of the -op tags. The misuse of this tag is also part of the problem which Denniz is having.

Garry Claridge · June 1, 2002

It should work. I just substituted 'localhost' for the IP address and my router is passing port 1154 through to my iBook which has FMP WC running on port 1154.

Those files are secure. They will show you as much as I want them to show you; of which I can vary at will.

All the best.

Garry

Garry Claridge · June 1, 2002

In reply to:

...over 3400 records were returned on a submission of b. This included any record in which any word began with b, such as Crawley Beauty. This is as useful as teats on a boar. Consider too that "bw" is the default operator.

Yes, "bw" seems to be acting like "cn". However, 'name===bloggs*' works OK.

All the best.

Garry

Anatoli · June 2, 2002

This link: http://139.130.177.9:1154/FMPro?-db=combotest.fp5&-lay=name_list&-format=testname.html&name=bloggs&-find

displays:

The page cannot be displayed

The page you are looking for is currently unavailable. The Web site might be experiencing technical difficulties, or you may need to adjust your browser settings.

I think the databases are open to "hacking" I didn't try much

scratchmalogicalwax · June 2, 2002

and we wonder why people are reluctant to post examples of their work

Garry Claridge · June 2, 2002

Unfortunately, I didn't have them open today. However, I will repeat that the databases are secure!!! You can only see what I want you to see; even with '-raw' and '-fmp_xml' etc.

I will open them now.

All the best.

Garry

Keith M. Davie · June 2, 2002

Garry, "Yes, "bw" seems to be acting like "cn". However, 'name===bloggs*' works OK."

Yes, I agree. It appears that '"bw" parameter (without a find operator) looks for anything in a string which contains that thing as itself (as in submit Beauty and receive Crawley Beauty). However, if the cdml reference is to be believed, "bw" should not be used without another find operator. That is why I say that using "bw" as in the example I gave is a misuse of that parameter.

"You can use any FileMaker Pro Find operator by specifying the begins with (bw) parameter.", cdml reference. This refers to the FileMaker Pro Find operators which are found in the Symbol pop-up of the db status bar in the Find Mode.

What John was trying to do was different from what the cdml reference says. The example given in the cdml reference presents this form action code:

While the second line presents a type="text", the value is hard-coded. This hard-coding will cause the entry of ==Keith* into the field for the find operation.

What we were trying was to avoid the hard-coding (value="") so the client can enter the word/letter to be found. The best we could do using cdml was create a situation where == Keith * was entered into the field for the find operation. The space between Keith and the asterisk causes unwanted results.

So while "...'name===bloggs*' works OK.", this too is hard-coded and thus not what was trying to be accomplished. Are you suggesting the use of a meta refresh wherein the link would be written in part "...name===token.0...*"?

With the form action there seems to be no way for a client submission to accomplish the desired "==Keith*" using cdml alone except to ask the client to enter the asterisk manually immediately following their submission criterium (without a space), as with the code example which I suggested.

BTW, the link is not working at this time.

Garry Claridge · June 2, 2002

In reply to:

The best we could do using cdml was create a situation where == Keith * was entered

Nothing a little bit of Javascript couldn't fix (or some bug-fixing by FM).

Whoops, I had nametest.html for the format file. That is dyslexia for you.

http://139.130.177.9:1154/FMPro?-db=combotest.fp5&-lay=name_list&-format=testname.html&name=bloggs&-find

All the best.

Keith M. Davie · June 2, 2002

Whoops, just noticed a slight error in my post of Today, 7:43 am. The line

"Are you suggesting the use of a meta refresh wherein the link would be written in part "...name===token.0...*"? "

should read

"Are you suggesting the use of a meta refresh wherein the link would be written in part "...name===token.0*..."? "

I erred in placing the elipsis. Sorry for any inconvenience or misunderstanding this may have caused.

Garry, the link is still not loading.

Sign In

Searching from the start of a field: ==puzzled*

Recommended Posts

john white ifc

Garry Claridge

john white ifc

Garry Claridge

Keith M. Davie

john white ifc

Keith M. Davie

Garry Claridge

Anatoli

Keith M. Davie

Garry Claridge

Garry Claridge

Anatoli

scratchmalogicalwax

Garry Claridge

Keith M. Davie

Garry Claridge

Keith M. Davie

Create an account or sign in to comment

Create an account

Sign in

Browse

Site Support

Forums

Blogs

Marketplace

Activity

Important Information