The RecordID is basically an internal field that FileMaker uses to keep
track of individual records, so an unique number is given to each
record when it is created.
Technically you can use this to identify records, but there is no
flexibility (eg. you cannot change this "field"). The RecordID is also
not static. If you import the records into another database (eg.
importing from a corrupt file into a fresh copy), then the record will
not necessarily get the same number.
It's usually much better to define your own "ID" field and use the
Auto-Enter Serial Number option.
Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)
Well, I was gone, then I came back. :)
Yes, Record IDs are always larger in creation order. I haven't tested
whether they sort by number or as text, which are different.
As Harry points out, Record IDs are not persistent. If you base a
creation sort on them, then sort by another field and import into a
clone, your creation sort is screwed.
Try this: Append a serial and a creation timestamp into a number
string, Timestamp first. Then sort by that field. It will persist
through all imports and be unique.
In fact, that's what I use for my keys. I don't need to reset the
serials after import, and the timestamps always ensure that even
repeated serials don't create a duplicate key.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
That would work, as long as when importing into another database you
remember to turn OFF the perform Auto-enter options. Other than not
being able to reset the counter, I can't really see why this would be
"more robust" than a normal Serial Number Field though.