Quick Find Bug?

[Dane]

I have a dirt-simple inventory DB, just started working on it, basically flat-file so far (i.e., no related tables in use yet), only 800 records, most fields still empty.

Quick Find is not working properly for me. If I use the Quick Find field to search for a part of a serial number, e.g., "DBT", I get no results. If I search for a longer string, i.e., more specific, "DBT30" I get one result. If I search for "DBT301" I get two results.

Neither record has this string anywhere in any field.

Oddly enough, the two records returned are two records I modified earlier today, may be coincidence, not sure.

Have tried this on my "main" layout, have also created an alternative, all-fields table-view data-dump layout, same results.

Saw another thread discussion where pop-overs were to blame, but I have no pop-overs, on either layout.

Suggestions?

Thanks.

[Lee Smith]

Are the quotes part of the data or did you add those to show the differences in what you used in your searches?

 

[Dane]

Added them to the description; not include in the search itself.

[dansmith65]

Have you reviewed the layout to see which fields have QuickFind enabled?

Is the serial number field defined as a number, or text field?

[Dane]

Most fields have Quick Find enabled; by and large I haven't gotten around to turning it off for fields where it's not useful yet. Early days.

Serial Number field is a text field, since they're frequently alpha-numeric.

What really puzzles me is that a more specific search criterion would generate more results, not fewer.

[Lee Smith]

Try going into the Storage Options and turning off Index, then go back to browse mode and then reenter and turn Indexing on.

[Dane]

Tried it with the Serial No. field, no change. 

Any way to do the whole file at once? Or is it just each field one at a time? I'm not sure which field the spurious match is being generated from, since it (the match) doesn't actually exist...

[dansmith65]

The advanced recovery options allow you to rebuild all field indexes, which is what you did on one field when you followed Lee's directions. You could test that.

If that doesn't work; it's going to be tedious finding out which exact field is causing the problem. There isn't any easy way to resolve it; you'll have to just be methodical and work your way through it. Not sure which field it's matching against? disable quickfind one field at a time until it stops matching.

[Lee Smith]

Hi Dan,

Doesn't Save AS >> Compacted Copy do that?

[comment]

2 hours ago, Dane said:

Serial Number field is a text field,

Are you sure about that? The reported behavior suggests it may be a Number field.

[dansmith65]

@Lee Smith I'm not sure; I'd like to know if it did, though. For the record, here's what I was referring to with the recovery option...

[Dane]

4 minutes ago, comment said:

Are you sure about that? The reported behavior suggests it may be a Number field.

Thank you, good point.

Started turning off Quick Find for various numeric fields, & found the one that seemed to be responsible for it. Not sure why it was matching that field, since it's a field that's never had any text. But DBT3W01 was matching 301. 

I can't recall ever bumping against this behavior before-- is this normal? I re-indexed the field, turned Quick Find back on for it, & still have the same problem. False positives are odd. 

 

[dansmith65]

33 minutes ago, Dane said:

I can't recall ever bumping against this behavior before-- is this normal?

Yes, I believe so. Since that field is defined as a number, it's index will only contain numbers. So the index for that value would contain: 301, which explains the match.

[Dane]

Er, but an index of 301 should not match the entry in the Quick Find box, DBT3W01. Unless the search routine filters alpha characters out of the searched-for text before comparison, but that makes no sense. That kind of processing would give you matches between, say, ASDF3GHJK4QWERTY5 and 345, which is nonsensical.

Will play around with a few other fields and entries, see what kind of matching I come up with. 

Thanks.

[comment]

8 minutes ago, Dane said:

That kind of processing would give you matches between, say, ASDF3GHJK4QWERTY5 and 345, which is nonsensical.

Yet that is exactly how it works.

[Dane]

Wow. Can't believe I've used FM for years and never bumped into this before. Ah, well, always something new to learn.

Thanks!

[dansmith65]

I think the reason it seems so strange is because number fields weren't meant to hold text and when you put text in them, they won't work like a text field. If you convert that field into a text field, your searches would work as you would expect them to.

[Dane]

 

1 hour ago, dansmith65 said:

I think the reason it seems so strange is because number fields weren't meant to hold text and when you put text in them, they won't work like a text field. If you convert that field into a text field, your searches would work as you would expect them to.

Yah, that I knew. But the issue here is my number fields don't have text, they only have numbers. It's the Quick Find criterion that has text in it. That's why I'm so puzzled.

[dansmith65]

Sorry, I had it backwards this whole time! Now I get why it seemed so strange; it seems strange to me too now.

But then again, if you do a regular old find in that number field with the text ASDF3GHJK4QWERTY5, it will match a record with number 345.

If you didn't want the text to cause a match in a regular find, you'd have to surround the value in quotes "ASDF3GHJK4QWERTY5", to make it match a phrase.

[comment]

18 minutes ago, dansmith65 said:

If you didn't want the text to cause a match in a regular find, you'd have to surround the value in quotes "ASDF3GHJK4QWERTY5", to make it match a phrase.

The thing is that you want DBT30 to find both DBT30 and DBT301 in a text field. Unfortunately, when using quick find it will also find 30 in a number field. The solution, IMHO, is to search only the field/s you want.

[Dane]

Oddly enough, putting the search term in quotes makes no difference... I guess Quick Find uses different rules than a regular find. 

As for why I'm using Quick Find instead of searching on a specific field, I've inherited a horrific data set where serial numbers might have been entered in any one of a half dozen different fields, depending upon the user doing the data entry. *sigh*

 

[comment]

20 minutes ago, Dane said:

Oddly enough, putting the search term in quotes makes no difference... I guess Quick Find uses different rules than a regular find. 

I am not sure that's the intended behavior. Quick find does use different rules than a regular find, but quotes are supported - in fact, "the only operator supported by quick find is the match phrase operator, double quotation marks (" ")."

OTOH, quotes are only defined as an operator for finding in text fields. So it's hard to say which behavior is correct when using them to search a number field: the quick find or the regular find.