Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
The Claris Museum: The Vault of FileMaker Antiquities at Claris Engage 2025! ×

This topic is 5188 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

I've run into a solution where the previous developer has chosen to use an auto-enter calculated value of get (RecordID) as the primary key field instead of the (to me) more traditional auto-enter serial number option.

After looking at the solution in more detail, to me it appears as if this option has a more dynamic solution (With obvious caveats, ie - not able to define "human friendly" pk fields and ODBC limitations are two examples that come to mind) especially when it comes to performing data syncing imports.

Are there any huge, show stopping limitations when it comes to using get (RecordID) as a primary key value that I don't know of? Is it slow/faster than using serial numbers or text fields as the primary key value? Are there any white papers out there that filemaker has made that explains this in more detail?

Edit: I think I just found a show stopper. get (RecordID) will always display the next higher value of the table, regardless of how many records were in the table previously. For example, if I have 40 values in a table with a primary key field set with the auto enter serial value checked, it will always go up by one, regardless of how many records I add or delete. If I have a field set to generate get (RecordID) it will only set that field as whatever number the record represents in the current table.

Say If I add five new records into the table:


Record  Result for get (RecordID) Result for next serial

1                    1                    1

2                    2                    2

3                    3                    3

4                    4                    4

5                    5                    5





Then I delete two of them





Record  Result for get (RecordID) Result for next serial

1                    1                    1

2                    2                    2

3                    3                    3





and add two more values





Record  Result for get (RecordID) Result for next serial

1                    1                    1

2                    2                    2

3                    3                    3

4                    4                    6         

5                    5                    7

I believe that qualifies as a show stopper. If ever had to archive values out of a main table and go back and reference them, there wouldn't be a real primary value (unique) since the record ID would be reclaimed if it was ever deleted. Is that correct?

Edited by Guest
Posted

Are there any huge, game-stopping limitations

Yes, I think there are: RecordIDs are file-specific and you have no control over them. If you ever decide to move your data to a new file, you'll have a major headache.

This topic is 5188 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.