Okay, here is a screenshot of the script with the two lines added. Thank you!
You have an extra find request being generated in both version of this script. As far as I can tell, that is harmless to your intended results, however.
Best guess is that you are getting a foundcount of 0 records and then your script exits and leaves you with a found set of zero matching records.
I suggest that you run your script and have it exit like you describe, then use modify last find to return to find mode and see what actual find criteria where specified for the find.
and if the _c indicates that this field, for some reason, is a calculation field, you might want to check and make sure that the correct result type is specified for it. (A calculation field with the wrong result type, such as specifying "Number" when the result is text, can result in a field that shows the correct value, but doesn't search, sort, or evaluate in calculations as expected.)
I did the "Modify Find" as you suggested, and even though typed: e04243
... the script stopped reading my input after e0 (see attached screenshot)
So it seems to be breaking at this line in the script: GetValue ($searchList ; $i)
... when the next value in the $searchList is a zero, rather than an alphabetic character.
I need a way to tell the script to treat every character as a text character, so I tried changing this line: GetValue ($searchList ; $i)
... to: GetValue (GetAsText($searchList) ; $i)
... but that also still stopped as soon as I typed the first zero after the letter E.
Any guidance is greatly appreciated. Thank you!
Is it possible that gSearchLive is defined as a global number field instead of a global text field?
Or is EventID_c a number field instead of a text field?
Good thought! I double-checked, because heavens knows that could have been it. They are both definitely Text Fields. And, FYI, the EventID_c is a Text Field with this Calculated Value: "E" & GetAsText ( Right ( EVNTNUM ; 5 ))
Thanks for your assistance!
"E" & GetAsText ( Right ( EVNTNUM ; 5 ))
will produce a value of "E1" when the value of EVNTNUM is 1. It should be
"E" & Right ( "00000" & EVNTNUM ; 5 )
Or you won't see any leading zeroes and the search criteria:
won't match to any values of EventID_c
PS Perhaps you are already aware of this, but I would not use EventID_c as a primary key for linking event records to other tables in your database... I might need it as a label, report or search field to support existing "legacy" systems and expectations, but I wouldn't use it in Manage | Database | Relationships.
Thanks. EVNTNUM is actually a ten-character text field that begins with E. — a legacy ID. But the users are accustomed to seeing a six-character representation, so I'm really just stripping out the unnecessary 4 zeros. :-)
Then I really don't see why "E0" doesn't match to records. You could use "E0*" but that wild card operator shouldn't be needed for a "starts with" type of find criterion.
One last shot in the dark: Is there any chance that "EO" is being used in your search instead of "E0"? (Confusing the letter O with the number 0 is a longstanding goof in computer programming....)
I appreciate that line of thought. I have a copy of the database myself, which I've been using in testing. And I have been extra-special-careful to type an E followed by zero followed a 4 (for E04427). I'm using a typeface that makes the numeral 0 quite distinct from the capital letter O. So unless I'm having a hallucination of some type, I'm certain the letter O is not being confused with the numeral zero. :-) Thanks!
If you just enter find mode on this layout and type in E04 into the EventID_c field and click perform find, does it find any records?
Yes, it does! Which, of course the users could do too. I was just trying to eliminate a step with the script. :-)
Yes but you miss my point. This was a test to rule out issues that might be keeping your script from working. One possibility being that the index for your field might be messed up. The fact that this manual find works suggests that either the wrong data is being used as search criteria, the wrong field is being searched, or perhaps there is a script trigger being tripped by your script and another script performed by that trigger is interfering with the results that you want.
If you have FileMaker Advanced, enable the script debugger and step through this script while monitoring field and variable values in the data viewer. you might spot what is not working for you and any interfering scripts performed by script triggers will pop up in the debugger.
If you do not have Advanced, give serious thought to spending the $$ to get a copy. The debugger alone can save you hours of trying to debug complex scripts. But without Advanced, you can try putting in a series of Show Custom Values steps in the script to pause the script at key points in your script--such as just before the find is performed. You can use the dialog to display the values of key variables and fields to further gain insight on what is happening here.