Perform Find screwing up randomly

Questions
1

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:

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:

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!

2

What does your $ID look like? Is it a UUID, and is the field configured as UNICODE?

Jan

3

It's a number, take a look at the results logged from the last failed run
I'll check the encoding configuration

4

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
Screenshot 2024-11-28 at 13.14.411264×1264 142 KB

5

Numbers don’t have encoding, only text does. Try to ensure that the script parameter is indeed a number.

Jan

6

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

7

According to the FileMaker help documentation, == matches a whole word or matches an empty value.

Jan

8

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

1 Like
9

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).

10

I'll test that, though FileMaker had never had any problem comparing numbers with strictly numerical strings, in my experience

11

Is there a global field involved?

See Find through global fields giving odd results

12

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

The post starts relative to the DataAPI but it can manifest in any find.

1 Like
13

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.

2 Likes
14

@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?

15

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.

3 Likes