Just done my first database clone to get rid of all the records in the development version. Thing is, I have noticed that the serial numbers have not reset back to 1. Not a biggie, I can manually do it, but surprised that's all.
Given what we do with clones, resetting the serial number fields as an automatic part of the process would cause more problems than it solved.
Saving a clone of a file and then importing all records from the first into the clone is a way to re-index all fields in the file, for example. If all the serial numbers reset, you'd have to go through every table, figure out the most recent serial number, and update the next serial numbers accordingly.
Resetting to zero when needed is a far simpler/safer task.
Goya also have a very good software tool to help you import all records from your live database into your development database. Retains original Serial Id's
RefreshFM | Automate your Updates
Works a treat.
yes and I've scripted such a process for years, but it's not what we are talking about here. Here, the discussion is why serial number settings don't reset to initial values when you save a clone of the file.
Apologies for the delay in responding, and thanks for all the replies.
I created a clone of the database (which is still not ready to be used by my client) as I was having some problems with date formats. It was suggested that because I started my database using Seedcode's DayBack Calendar as the base, it would be worthwhile me cloning it as that may return the date functions to working correctly (i.e. taking on my preference of UK over USA date formats). This worked.
I assumed that if you cloned the database, it would strip all old records out and revert it to a brand new, empty instance. Obviously not.
I will just need to make a note to return all serial numbers to zero when I clone it again to take it from the Development Database, to the Database my client will eventually start using.
First FileMaker project, so still rather wet behind the ears!
Why bother? The fact that the serial value doesn't start as one for the first new record is rarely necessary.
Well, I am using the serial number as a sort of of "reference" as well. So for a "job" the reference is "J-" & SerialNumber. For a quote, the reference is "Q-" & SerialNumber etc etc.
I would just like the first number to be 1!
Fair enough and it's easy to reset to zero. You can even use scripts to do it.
But much of the time, serial numbers are used as primary keys that are not visible to the user. Note that even in this case, it's not strictly necessary to do.
J_File wrote: Well, I am using the serial number as a sort of of "reference" as well. So for a "job" the reference is "J-" & SerialNumber. For a quote, the reference is "Q-" & SerialNumber etc etc. I would just like the first number to be 1! James
From purist point of view you are misusing the primary key because you are assigning meaning to it. The actual value of the primary key should not matter, as long as it is unique, because it is purely meant to make the table relationships work and some other strictly behind-the-scenes database operations.
You're displaying it to the user and now the primary key becomes something meaningful that has to follow rules.
I would strongly suggest you use a separate field with a separate incrementor for the reference and leave the primary key to do its job.
Also there is the fact that you may need/want it to start at some other value other than 1, such as 1000 or 10000
i use uuids for primary keys. Wouldn't trust the serial number function to do that!
i am happy wth how I am using them. I will just reset them all to 1 when I am ready. In fact my client may want me toreaet them to another number to start with like 10000.
We shall see.
Both UUID's have their strengths and weaknesses.
If you understand those, serial ID's--which have been used for primary keys in FileMaker for years. They do the job. I use either one based on what seems the best fit for the solution.
Retrieving data ...