# Perform Find screwing up randomly **URL:** \ **Category:** Questions\ **Tags:** scripting\ **Created:** [November 28, 2024, 11:08am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509 "2024-11-28T11:08:17Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 11:08am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/1 "2024-11-28T11:08:17Z")
Hey there, I've been using FileMaker for over a decade now, but this weird behavior is a first for me The failing part of my script works like so: ```auto Set Variable [$Manual ; Value: IsEmpty ( Get ( ScriptParameter ) )] Set Variable [$ID ; Value: If ( $Manual ; All Schedules::ID ; Get ( ScriptParameter ) )] New Window [Style: Document ; Using layout: “Manage Schedule” (SCHEDULE)] Set Error Capture [On] Perform Find [Restore] # FIND [SCHEDULE::ID ==$ID] ``` When called by the server, the script parameter is always supplied. This script is called every morning, and usually succeeds After the find request, I log `Get ( ScriptParameter )`, `$ID`, and `SCHEDULE::ID` The weird thing is, sometimes, seemingly at random, it will simply fetch the wrong records! When running the script again, with the exact same parameters, also from the server, it suddenly works, as if trying to hide the bugs. ## Latest failure, yesterday, logged the following Script Parameter: 32970 $ID: 32970 Schedule ID: 1247 It is always Schedule 1247, it is the seventh record, and the first that is also connected to MAIN So, when doing `SCHEDULE::ID` from the MAIN single-record table, the first record returned is ID 1247 But why would that be related to a Perform Find request that runs on a SCHEDULE layout, with a numeral $ID supplied by the script parameter?? I've been trying to track this error for two months now and I've no clue as to why a simple find request of `SCHEDULE::ID ==$ID` fetches the wrong $ID! * * * Furthermore, I implemented a check after the find result that goes like so: ```auto If [SCHEDULE::ID ≠ $ID] # Schedule mismatch Perform Script [...] // Log error and data Close Window [Current Window] Exit Script [Text Result:] End If ``` And this does not fire! It passes as if it didn't fail, then it continues on with the wrong Schedule! ---
**Author:** ![janhagemeister](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@janhagemeister](https://the.fmsoup.org/u/janhagemeister)\ **Post date:** [November 28, 2024, 11:12am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/2 "2024-11-28T11:12:43Z")
What does your $ID look like? Is it a UUID, and is the field configured as UNICODE? Jan ---
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 11:13am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/3 "2024-11-28T11:13:21Z")
It's a number, take a look at the results logged from the last failed run I'll check the encoding configuration ---
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 11:15am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/4 "2024-11-28T11:15:26Z")
I do not see anything about the encoding, it is a simple number field created with auto-enter serial ![Screenshot 2024-11-28 at 13.14.41](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/8/8406c6ab762ab1e6cbfd05c1c3fbd8a3e1601325.jpeg) ---
**Author:** ![janhagemeister](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@janhagemeister](https://the.fmsoup.org/u/janhagemeister)\ **Post date:** [November 28, 2024, 11:20am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/5 "2024-11-28T11:20:09Z")
Numbers don’t have encoding, only text does. Try to ensure that the script parameter is indeed a number. Jan ---
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 11:20am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/6 "2024-11-28T11:20:28Z")
You mean as in 32970 and not "32970"? With a find request, adding "==" in filemaker, it should turn into a string and finds the right numbers anyway, no? As in - I never had a problem finding numbers using numerical strings ---
**Author:** ![janhagemeister](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@janhagemeister](https://the.fmsoup.org/u/janhagemeister)\ **Post date:** [November 28, 2024, 11:26am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/7 "2024-11-28T11:26:07Z")
According to the FileMaker help documentation, == matches a whole word or matches an empty value. Jan ---
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 11:27am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/8 "2024-11-28T11:27:08Z")
This does not really have anything to do with what I asked Also no, == matches whole string, = matches whole word And so.. ==$ID should match the entire number ---
**Author:** ![janhagemeister](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@janhagemeister](https://the.fmsoup.org/u/janhagemeister)\ **Post date:** [November 28, 2024, 11:42am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/9 "2024-11-28T11:42:47Z")
It’s just a guess, but you might be comparing the field scheduleID (Number) with a String. Instead of writing schedule::ID ≠ $ID, I would suggest using schedule::ID = NOT GetAsNumber($ID). This would attempt to compare schedule::ID to the result of NOT GetAsNumber($ID). ---
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 11:48am UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/10 "2024-11-28T11:48:16Z")
I'll test that, though FileMaker had never had any problem comparing numbers with strictly numerical strings, in my experience ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [November 28, 2024, 2:18pm UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/11 "2024-11-28T14:18:14Z")
Is there a global field involved? See [Find through global fields giving odd results](https://the.fmsoup.org/t/find-through-global-fields-giving-odd-results/3389) ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [November 28, 2024, 2:38pm UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/12 "2024-11-28T14:38:11Z")
I see you posted to the Claris community. Here is an existing thread there that is likely relevant: Here is some potentially related info: [https://community.claris.com/en/s/question/0D5Vy00000Cxjc1KAB/insufficient-privileges-error-code-9-on-find-request-where-privileges-should-allow-it](https://community.claris.com/en/s/question/0D5Vy00000Cxjc1KAB/insufficient-privileges-error-code-9-on-find-request-where-privileges-should-allow-it) The post starts relative to the DataAPI but it can manifest in any find. ---
**Author:** ![bdbd](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bdbd/32/620_2.png) [@bdbd](https://the.fmsoup.org/u/bdbd)\ **Post date:** [November 28, 2024, 5:09pm UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/13 "2024-11-28T17:09:05Z")
You don't need to specify == or = when finding a value in a number field. Find always searches for the exact value in number fields. You may have a corrupt index. Perform these steps to fix a corrupt index. (This can safely be done whether you have a corrupt index or not.) 1. Kill the existing index: - open manage database; - display the options for the number field; - display the storage tab; - select none for indexing; - click OK to close the field options; - click OK again to close the manage database window. 1. rebuild the index: - open manage database again; - display the options for the number field; - display the storage tab; - select all for indexing; - click OK to close the field options; - click OK again to close the manage database window. Give FileMaker or FileMaker Server a bit of time to rebuild the index. How much depends on the number of records to index. Then see if your script still returns wonky result. If not, you had a corrupt index. ---
**Author:** ![DeanAyalon](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@DeanAyalon](https://the.fmsoup.org/u/DeanAyalon)\ **Post date:** [November 28, 2024, 8:14pm UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/14 "2024-11-28T20:14:54Z")
@xochi no global fields used in this script @Kirk I’ll take a look, thank you @bdbd I’ll definitely try that, however, had the index been broken, wouldn’t all runs fail rather than happening at seemingly random times? ---
**Author:** ![bdbd](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bdbd/32/620_2.png) [@bdbd](https://the.fmsoup.org/u/bdbd)\ **Post date:** [November 28, 2024, 9:39pm UTC](https://the.fmsoup.org/t/perform-find-screwing-up-randomly/4509/15 "2024-11-28T21:39:39Z")
I am inclined to say that a broken index can sometime return valid values. I've seen the behaviour you posted and the fix was to rebuild the index.