They exist to access an already created Record. At Write a Record time, SQLite create them and store them in the Record into the TABLE (more complex, but you get the idea).
Assuming you are working with SQLite, there is a good explanation about rowid and primary key, and the potential alias, in the Xojo docs. Look just below the list of result codes:
Since dbRowID is user defined… the user/app can do whatever it wants to that value, causing it to not match the corresponding Primary Key value. When records are deleted, the Primary key values WILL have gaps. And if dbRowID is a simple incremented value. they may or may not continue to match from the point of a deletion forward. And finally, if the intent if for dbRowID and Primary Key TO match… then why bother having both to begin with? (FYI… SQLite creates a ROWID regardless of if you ask it to or not, and USES it as the PK if you indicate an INTEGER PK datatype)
Work with a primary key as it’s the only thing guaranteed to stay the same. RowID is not guaranteed.
Let the database define the value for that primary key since they’re really good at it (and designed to to it). Don’t ever think you can do a better job at creating a primary key value than the database (and the millions of people that use them every day can attest to). If you think you can - you are wrong.