Search that contains a @ character fails

[mike_tcis]

I'm trying to search on a value that contains a @ character (specifically, an E-mail address). My code is as follows:

[FMP-InlineAction: -db=Services_.fp5, -lay=Web, -Max=10, -SortField=Email Name, Email Name="[email protected]", -Op=neq, Delete Flag=1, Email Customer ID={FMP-Field: Customer ID}, -Find]

If I search on any part of the address besides the @ sign, everything works fine. I've tried it with and without quotes. If anyone has any insight as to what magic I must work to get this going, it would be much appreciated..

[Garry Claridge]

You could try an exact match, e.g.:

FMP-InlineAction: -db=Services_.fp5, -lay=Web, -Max=10, -SortField=Email Name, Email Name="[email protected]", -Op=neq, Delete Flag=1, Email Customer ID={FMP-Field: Customer ID}, -Find]

Have a look at the database using "Modify Last Find" after you attempt to use the InlineAction. This will tell you what the actual search looked like to the database.

Good Luck.

Garry

[Unable]

Well now, here is an interesting situation.

It is very useful to understand the database operations.

For instance, if one performs a find in the db, in the Status Bar one is offered a button "Symbols" and one finds "@ one character". In other words, the "@" is a "reserved" character used in db find operations. As a "reserved" character it can only be used for its specific purpose.

Put more succinctly, you cannot successfully perform a search on an email address (or any data string) which contains the "@" character.

You will need to use a calculated field or some other method.

It is not magic.

[mike_tcis]

Actually, Garry's suggestion above *does* allow me to search on an E-mail address. However, it is an exact match only. So, I'm going to offer two search boxes -- one for an exact address and the other for a part of the address.

[Leb i Sol]

exact search is what you should be doing....since there are NO valid Emails that are the same...if you need to seach for a "part" of an email addres then have users seach for for the domain and user name separatly:

<form name="form1" method="post" action="FMPro">

  <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Please Enter a UserName 

    or Domain:</font></p>

  <p> <font size="2" face="Verdana, Arial, Helvetica, sans-serif">

    <input name="-eq" type="hidden" id="-eq" value="cn">

    <input name="Email" type="text" id="Email" size="15">

    @ 

    <input name="-op" type="hidden" id="-op" value="cn">

    <input name="Email" type="text" id="Email" size="15">

    </font> </p>

</form>

I guess it depents what you plan to use this info for..how many emails are the same domain...or how many records...maybe you can record emails into a split 2-fields in DB and 2 fileds in the Form search....well....

go get lucky

[Unable]

I stand corrected.

A find involving a reserved character can work with a "field content match" (==); it also can work with an exact match (= or eq).

Without either it seems to not find.

Which explains why the original code was not working.

[cjaeger]

For instance, if one performs a find in the db, in the Status Bar one is offered a button "Symbols" and one finds "@ one character". In other words, the "@" is a "reserved" character used in db find operations. As a "reserved" character it can only be used for its specific purpose.

Right.

Put more succinctly, you cannot successfully perform a search on an email address (or any data string) which contains the "@" character.

WRONG

You will have to enter "@" - with the quotes - to successfully find any email address containing the @ character. or "*" to find any record with a * character ....

Sometimes it helps to take a trip to FileMaker Help.

[Unable]

CJ, actually that statement is correct in relation to the code as originally posited, i.e., [email protected], when entered in a search field without a modifying operator, will not work because of the "reserved" character.

The effect of an acceptable modifying character is to modify the inappropriate data string to a something which, in effect, makes the reserved character appropriate, in one form or another, for the event to succeed.

In addition to the acceptable modifiers "exact match" and "field contents match" mentioned above, you have added "quotes" to the list of acceptable modifiers. Entering them through a browser can be problematical. Similarly, if one chooses to use symbols in a find, that can be problematical if one tries to mix metaphors.

Cheers.

[Garry Claridge]

Re: if one tries to mix metaphors

We have a local all-girl band called "Mixed-Metaphors". Great music

All the best.

Garry

[cjaeger]

>Similarly, if one chooses to use symbols in a find, that can be problematical if one tries to mix metaphors

you have a point there ...

[surwoop]

You could try using ASCII as the indexing language for your field.

[cjaeger]

... but that would not help with FileMaker "reserved" characters ...

[Pupiweb]

As far as I remember the ASCII indexing should work

Other workarounds include the use of a calc field substituting the @ sign with a space

[Bob476]

I tried the ASCII solution and at first it seemed to solve the problem, but now the search is case-sensitive, and my database of emails has lots of varied case entires, AOL.com, aol.com, etc. So I'm not sure whether there's a case-search value I can toggle or just go back to searching with "'s.

[surwoop]

You could define a calculation field using the lower function & use it as your search field.

e.g.

EmailSearchField =

Lower (EmailAddress)

Your users would need to type their search criteria in lower case.