My users send bulk email to clients.

When they receive an undeliverable notice in reply, they enter find mode, paste the email address back in the field and return the find to find out who belongs to the email address. That follows what they have been taught about performing finds in Filemaker.

Unfortunately the search always comes up empty - I think because Filemaker reads the @ as a single wildcard character.

The email address is actually there and "Find matching records" works fine in the field from browse mode.

It also works works if you precede with == but that then rules out part address finds. It works if you put " " around the @, and it greatly narrows the search if you just use the characters preceding @, but the number and turnover of staff means that explaining this would be an ongoing process, so I'm looking for a more user friendly solution.

Is there a quick and easy solution to this problem, keeping in mind that I have data validation to ensure the existence of a @ and a . and an auto enter calc to remove unwanted characters, spaces and returns?

I tried to use a script trigger in find mode to find/replace @ with "@" or @ but for some reason the script will not accept the ""@"" that I think I need to use to specify the replace and single quotation marks ("@") has no effect on the result.

You need to Find/Replace "@" with ""@"" or - preferably - use the Substitute() function, with "@" as the replaceString.

I'd be inclined to give them a 'find by email address' button, calling a script which:

1) shows a custom dialog for the email address, with a global input field

2) user pastes the bounced email address in to the input field

3) script checks the input field for presence of @ and . and maybe also grumbles if there are illegal characters such as brackets, quotes, spaces etc

4) script enters find mode

5) script sets email field to """ & globalField & """ (i.e. wraps the user's input in quotes)

6) script performs find

This would give results more in line with what the average non-FileMaker-user might expect.

J

Thanks Comment, that works nicely.

Thanks also James

One way to solve this problem is to set the field definition to use unicode, although this will require the search text to be in the correct case. (upper case, proper case or lower case)

See the attached images, how to set the field to unicode.

Thanks Amram - it's amazing how many different solutions there can be!