Finding emails with upper and lower case

[JGF]

I am having trouble when performing finds in our email field. What is happeing is that I usually have an email in lowercase to search with and some of the data has uppercase. This makes it hard to search since email address is the one field I always use to perform a search. Is there any way to make it find both cases with one search?

tia

Joshua

P.s. Filemaker is retarded when it comes to email, they have the @ symbol as a reserved character!?!

[Lee Smith]

I believe you can escape the charater in v7, I can't upgrade to v7 due to system restrictions, but check your manual or online help about Regular Expressions. and the special characters such as @, =, etc.

HTH

Lee

[-Queue-]

If the field is indexed in English, then it should be case-insensitive on searches. To include the @ in your search, just enclose it with quotes, e.g. "@something.com" or "jgf@".

[JGF]

I tried indexing in english and that made it worse, so I switched back to unicode.

tia

Joshua

p.s. I know about the "" and also that I can escape @ with a /

[-Queue-]

Unicode will be case-sensitive. There's nothing you can do about that except force all entries to be in a single case or create a calculation of Lower(field) and do your searches in the calculation field in lowercase.

[JGF]

I am still having this same problem? does anyone have any experience with storing emails under something other than unicode, if so how are you retrieving those records, when I changed mine to english I couldn't find anything by simply putting in the email I was looking for.

TIY

[-Queue-]

You could use two calcs to break your address into 'name' and 'domain', then perform your searches in those fields. @ will no longer be an issue, and 'English' may work better.

[sbg2]

I have figured out a way but the calcs in FM work strangely. I tried a calculation to replace the @ symbol with ~at~ but it produced truncated text. I duplicated that calculation field and all the sudden the duplicate works? very strange stuff.

Anyways, the attached file will work for me.

[sbg2]

I have figured out a way but the calcs in FM work strangely. I tried a calculation to replace the @ symbol with ~at~ but it produced truncated text. I duplicated that calculation field and all the sudden the duplicate works? very strange stuff.

Anyways, the attached file will work for me.

[sbg2]

I have figured out a way but the calcs in FM work strangely. I tried a calculation to replace the @ symbol with ~at~ but it produced truncated text. I duplicated that calculation field and all the sudden the duplicate works? very strange stuff.

Anyways, the attached file will work for me.

z_EmailFind.zip

[-Queue-]

There you go. That's another way to do it.

Was your original field perhaps in the wrong format, i.e. number instead of text?

[-Queue-]

There you go. That's another way to do it.

Was your original field perhaps in the wrong format, i.e. number instead of text?

[-Queue-]

There you go. That's another way to do it.

Was your original field perhaps in the wrong format, i.e. number instead of text?

[sbg2]

I'm not sure, but I did create a new file right afterwards to repeat the test and got the same weird results. Just now I created a 3rd file and this time the calculation field worked right the first time, no duplicating needed. It may be user error but I still cant find the difference.

Hmmmm Ok, here's a good chuckle.... As always I'm working on this between my 50 other job duties... scatterbrained. If the bounds of the field are not big enough to show the full text it will truncate what is displayed. Duh, make the field bigger dummy , maybe you're right I started the field as a Calc Result Is Number and fixed the result to be text but never resized the field on the layout. what a maroon!

[sbg2]

I'm not sure, but I did create a new file right afterwards to repeat the test and got the same weird results. Just now I created a 3rd file and this time the calculation field worked right the first time, no duplicating needed. It may be user error but I still cant find the difference.

Hmmmm Ok, here's a good chuckle.... As always I'm working on this between my 50 other job duties... scatterbrained. If the bounds of the field are not big enough to show the full text it will truncate what is displayed. Duh, make the field bigger dummy , maybe you're right I started the field as a Calc Result Is Number and fixed the result to be text but never resized the field on the layout. what a maroon!

[sbg2]

I'm not sure, but I did create a new file right afterwards to repeat the test and got the same weird results. Just now I created a 3rd file and this time the calculation field worked right the first time, no duplicating needed. It may be user error but I still cant find the difference.

Hmmmm Ok, here's a good chuckle.... As always I'm working on this between my 50 other job duties... scatterbrained. If the bounds of the field are not big enough to show the full text it will truncate what is displayed. Duh, make the field bigger dummy , maybe you're right I started the field as a Calc Result Is Number and fixed the result to be text but never resized the field on the layout. what a maroon!

[-Queue-]

Hey, no sweat. I've done that before. At least now you will know to check for that possibility in the future when 'something is not quite right'.

[-Queue-]

Hey, no sweat. I've done that before. At least now you will know to check for that possibility in the future when 'something is not quite right'.

[-Queue-]

Hey, no sweat. I've done that before. At least now you will know to check for that possibility in the future when 'something is not quite right'.