can you post some examples you think should be found and/or as a duplicate?
the find symbols are tricky at times, but knowing your data and what to search helps.
Possible issues that come to mind (I'm guessing a lot here though)
You mention finding emails. If you are searching on an email address field, a common gotcha (it's tripped me up several times) is that the @ symbol is itself a special find operator. So if you use, say *@.somedomain.com as your search criteria, the @ is treated as a find operator not as text that is part of your search pattern. To fix this, use quotes: *"@.somedomain.com".
You mention duplicates. One issue I encountered that has to do with finding duplicates and how FileMakers indexes function is that using the ! operator to find duplicates can fail if you are using it in a text field where there are returns separating different blocks of text. You won't get the results you would normally expect in this case as each return separated chunk of text is checked against all the other chunks for possible duplication. Thus, if you enter 3 paragraphs of text into a text field and then do a ! search on it, you may pull up several records because the last paragraph is the same in each even though the other paragraphs in the field are different. (Note: It was quite a few versions ago when this issue came to my attention here in the forums so it's always possible that newer versions no longer do it this way.)
I appreciate the above comments: Not a cure.
My examples did not include using the @ in my search in the case of:
and my list of 5 (example only is this on a much greater volume scale:
lets say for example, my search only gave me one email---
Then for dupes, lets say it did not find the one duplicate.........
I'm not sure why this is the case, but if I used either of the following criteria, I found all of the above examples in FileMaker Adv 15:
That @ does seem to be affecting how the text in the field is indexed.
i worked all night to manually go through emails.
The @ was not part of the search *"" I had 1,000's after only finding 200 or so?
Searching end words was ok, like gmail.com 100%
dupes were also exact matchs no returns, single line email address's
I tried and tried with same result... rebooted.... glitch in volume of files?? 18,000 emails
using *"marine" i got 357 found of 18,101
using *marine* it found 2102
I am not saying that @ was part of the search criteria but that it seemed to affect how the data in the text field is indexed and thus affected my search results.
When I used:
*dive or *"dive", the entries not found were:
Note that in both cases, there is text after "dive" but before the @
The other records, the ones found, all have the pattern dive@
To be more clear, the @ seems to be functioning as a word separating character and thus *dive finds text such as:
as "@aol.com" is treated as a separate word.
The solution is to add the extra wild card at the end to use:
In order to find both text patterns in your table.
I would search:
(anything before the sequence of characters and anything after the sequence) Perhaps the quotes are the problem?
As for duplicates, I never had good results on email fields. You might pull them apart into two fields (one with before "@" and one after), then look for duplicates with "!" in both fields.
There could also be hidden values (space, tab, return) that are of course invisible to us carbon-based life forms, but 'something' to the silicon.
there it is: carbon based life forms...... time for lunch, still frustrated that it didn't work, and that I can't get it to do it all at once.
dupes, i don't know what to think. they are the same!
it got most.
? side question. Is there an easy way or way to eliminate 1 of 2 if duped?
or 2 or 3 leaving only one?
Feed the carbon!
I've never trusted the 'dedup' as a program. Usually there are other fields that are not the same (name, address, phone) even though the eddress is the same. I just take the time to review and manually omit the top/good one and eliminate what's left. (sort by that field to group them together, first!)
Frankly, I don't know exactly what your are doing with the ! and what results you want to see. That would help us to help you.
I often use import records to produce a "clean" table free of duplicate entries in a specific field. To do this, you set up validation rules on that field: Unique Values; validate always.
Then, when you import the data into an empty copy of this table (could be a clone of your file), the records where there is a duplicate in this field are omitted.
Obviously, you'd try this with a copy of your files so that you can toss them and revert back to your original if you get unexpected results.