When searching for a street address by number, e.g. 12035, I am also getting matches based on the Primary Key in other tables (e.g. phone and email, where the Record ID matches 12035). For both phone and email tables, only one field each is set up to be searched (one phone field for Phones and one email field for Emails). I don't see anywhere in the scripts where the field with the object name of UniqueID gets searched but I might be missing something. I don't want the primary key fields included in the search and would like to suppress this in most cases.

Hi Hedrich,

I think you've discovered a bug, but I think I have the fix. Even though you don't have the Unique ID set up as search field, that's actually the active field when the search process begins (first item in the tab order), so if the first Go To Object step fails because the item has been removed, then it keeps it's focus on the primary key field and inserts the search string into the Unique ID field. I'll confirm this with the developer, but it looks like adding a Commit Record/Request step after entering find mode boots you out of the Unique ID fields and prevents it from being included in the search:



I'm pretty sure that's it, but please let us know.

Cheers!

Awesome! Thanks. I'll give it a shot tomorrow and let you know.

OK, I just gave it a shot in my solution but that did not resolve the issue for me. It still seems to search on the Unique ID fields on those two tables.

Hi Hedrich,

Hmmm? I think it's probably something related, where the UniqueID field is getting a value dropped into it in find mode in the above script. Unfortunately, I'm heading out for the Holidays until Tuesday, but I'd like to take a peak at your file when I get back if you haven't tracked it down. [email protected]

Cheers!
Jason

Actually, I did figure it out and sent a detailed message to Matt with my findings and solution. I'll post it here in just a sec.

I tested some more with the script debugger. In the fmSearchResults layout templates, there are only two Integer fields (Number01 and Number02) included. But the script is trying to process four. So if I supply an integer value as a search string, the script is going to try to go to an object (Number03) that doesn't exist and that is when it ends up on the UniqueID object. It only turned up for me in these two tables because they have lower starting primary key field values than the other tables in the solution. I think the main thing is that, unless you don't mind search results that include a search on the primary key, it's important that the number of objects of each data type on the search layouts matches the number of objects of that data type referenced in the script, even if those objects aren't linked to an actual field. Otherwise the UniqueID field will likely be included in the fields to search.

So in the script I just commented out the references to Number03 and Number04 and all is well. If I ever need to search for more than 2 integers, I know what to do.

Excellent!