Are you looking to start with an empty database with the next PK set to a starting value? You can do this manually (deleting all records and setting the next serial number in Manage Database to your desired value), or one could script it (delete all records then use the Set Next Serial Value function).
Hi deninger, thanks for that, I thought so just checking incase I was going the long way around things ..
Hi Mark - as part of a script that you might create to set the next serial number of each desired field, it is worth including the creation of any records that you might need for settings or as default data to make the solution work seamlessly on first open. I have still found serial numbers annoying in some cases when updating client databases... a UUID in my opinion can be a little easier to use for setting primary keys.
I'm back with the "Primary Key auto serial" commonly called "surrogate key" see http://en.wikipedia.org/wiki/Surrogate_key.
- Surrogate (1) – Hall, Owlett and Codd (1976)
- A surrogate represents an entity in the outside world. The surrogate is internally generated by the system but is nevertheless visible to the user or application.
- Surrogate (2) – Wieringa and De Jonge (1991)
- A surrogate represents an object in the database itself. The surrogate is internally generated by the system and is invisible to the user or application.
So no matter their values in a reset to zero.
The problem is when syncing mobile base not connect, which is a complex subject involving concepts of timestamp.
Hi Thanks for that..yess good point about having some data in the DB for seemless start..cheers
Very interesting about surrodate keys..thanks
Ive had a quick look..Ive book marked it to have read later...cheers
1 of 1 people found this helpful
Hi Mark - It stands for Universally Unique Identifier. The primary key can be set as a text field with the auto-enter calculation "Get(UUID)" using FileMaker 12. You then don't need to worry about resetting the next auto-enter serial number with updates or some imports. It is ugly to look at (36 alphanumeric characters), but most or many tables probably don't need a visible unique ID. If they do, then a separate serial number could also be generated for that purpose (e.g. invoice number, file number etc.).
Thats great.. thanks for that and good to know.
I do not want to discuss a standart set in 1992 (ANSI SQL 92) and if you refer to the link http://en.wikipedia.org/wiki/Surrogate_key the definition of surrogate key is very clear:
the single value is system-wide, hence never reused
the value is system generated
the value is not manipulated by the user or implementation
the value contains no semantic meaning
the value is not visible to the user or implementation
the value is not composed of several values from different domains.
I understand your position, but I also see that you confuse the primary key with a semantic identifier, eg factureID and facturePK.
The problem with FM is that it do not handle real primary and foreign declarative constraint. In addition, everything is in the same file, schema, views and controls (MVC) makes it very difficult to update the application and data synchronization.
I like mostly FM and FM Go, but it is not a true relational DB. Apple uses Sqlite and not FM.
My suggestion is not a scientific essay but a simple implementation for FileMaker. That said, I see no contradiction between the "definition of surrogate key" and my solution.
I do not confuse anything - no matter how you name the child or where that "key" is generated. Moreover, my solution handles typical FileMaker problems, like cloning, duplicating of records and import of records with or without a pre-existing "key".
Whether FM is "true rational," what standards were set in 1992, or which databases Apple uses has nothing at all to do with the underlying problem.
I'm sorry, I do not criticize the way you do, but weak FM.
I still have the link on your website and soon we could continue this discution.