Find an exact email address or literal symbol in FileMaker

Example status

Native fixed-find and return-window checks passed

Scope and what still needs checking

FileMaker Pro desktop; text fields. These fixed examples are not a general-purpose encoder for arbitrary user input.

FileMaker Pro 26.0.3: exact escaped email, literal asterisk and equals sign, no match, unescaped comparison, and duplicate-email membership. The unescaped email matched an unintended lookalike; the exact escaped criterion returned the expected IDs. A separate no-match window showed zero records; closing it preserved the caller’s Contacts layout, selected S03 and one-record found set. A blank raw find returned error 400 while retaining the prior found set. Text indexing language: Unicode.

This verifies the fixed examples in a local Full Access laboratory, not a general-purpose search box. Reject empty user input before Find and never display a previous found set as a successful new search. Check these cases in your intended file before adopting the pattern.

Readable script fragments must be recreated in Script Workspace. Pseudocode describes a design, not an executable script. Use a disposable working copy.

Get the review data and expected results ↓

Why an ordinary email find can surprise you

A search box may look like a place to type plain text, but a FileMaker find request also accepts operators. The @ character can stand for one unknown character. A star can stand for a sequence. An email address or product code containing those characters needs a deliberate search rule.

There are two separate decisions: whether the whole field must match, and whether punctuation is literal. Use == for whole-field matching and escape special characters you mean literally. This is not a case-sensitive identity test. If your business rule distinguishes case or Unicode variants, check the stored text separately.

Start in a disposable contact file with text fields ContactID and Email. Use the small CSV linked below. Keep one email per field; a field containing several addresses is a different search problem.

Try three explicit criteria

On a small screen, scroll the table sideways to see every column.

Goal	Enter in Find mode	Expected fixture IDs
Only ana@example.com	`==ana\@example.com`	E01
Only the code A*B	`==A\*B`	S01 in the Code field
Only the code A=B	`==A\=B`	S03 in the Code field

The sample also contains ana@example.com.au and anaxexample.com. They make an overly broad result visible. A result count of one is not enough by itself: inspect ContactID to establish which record was found. Duplicate stored addresses would legitimately return several records.

Recreate a fixed email search

Create a layout named Contacts based on the Contacts table occurrence. Run this example in a separate review window so the caller’s found set stays intact. Commit or cancel existing edits before opening that window; do not silently save a customer’s unfinished changes.

Readable FileMaker script · fixed review example

Set Error Capture [ On ]
Go to Layout [ "Contacts" (Contacts) ]
Enter Find Mode [ Pause: Off ]
Set Field [ Contacts::Email ; "==ana\\@example.com" ]
Perform Find [ ]
Set Variable [ $error ; Value: Get ( LastError ) ]
If [ $error = 401 ]
    Exit Script [ Text Result: "No matching email address." ]
Else If [ $error <> 0 ]
    Exit Script [ Text Result: "Find failed: " & $error ]
End If
Exit Script [ Text Result: Get ( FoundCount ) ]

The calculation string contains two backslashes so that its resulting find criterion contains one. This distinction matters when moving a manually tested criterion into Set Field. Recreate the steps using FileMaker’s selectors; this text is not a clipboard script import.

Do not turn the fixed example into an unsafe search box

A general search feature must decide what an empty value means, whether wildcards are allowed and how to handle quotes and backslashes. Concatenating "==" & $input does not by itself make arbitrary input literal. Keep a deliberate advanced-search mode separate from an exact-address control.

For an ordinary exact-search control, reject empty input before entering Find mode. In the local native check, an empty raw request returned error 400 and left the prior found set available. Check the error before reading a count or presenting records as new results; 400 is not the same as a valid search with no matches (401).

If you need byte-for-byte comparison, first find a manageable candidate set and compare each candidate with your documented normalization rule. Do not silently trim or lowercase source identifiers merely to make a test pass.

Check the boundary cases

Run the three criteria against the fixture and record IDs, not just counts. Then test an absent address, a deliberately duplicated address, blank input, and the ordinary unescaped address for comparison. Confirm that the no-match message leaves the review window empty and does not show stale results.

Finally close the review window and confirm that the original layout, selected record and filters are still present. Record the FileMaker version, platform and field indexing language with the result.

Try the small review fixture

The fictional data and review notes below accompany this article. They are not a FileMaker application, and they do not establish native test results.

References

Documentation checked on 21 October 2026. This review does not establish native execution or hosted compatibility.