You're probably going to have to explain a lot more about what you're trying to accomplish. What do the Unique IDs represent? The Models? What is the entity represented in the table? (To answer that one, answer the question "what does each single row in the table represent?".) Right now, I'm afraid it's all too vague for anyone to chime in with a definitive reply.
Depending on those answers, there's a chance you'll need to divide (normalize) it into two separate tables.
A well established set of FM principles is that:
1. every record in every table should have a unique ID
2. that ID should be, from the user point of view, meaningless data
3. that ID is the field you use for FM purposes only, to build relationships
4. any data you want to be meaningful to users—including unique part numbers (IDs if you will)—should be entirely separate from the unique ID that FM uses (see 1 to 3 above).
If you want the model ID you appear to be demonstrating in your very limited post to be meaningful, go ahead and make it using a calc based on other field data, as you appear to be thinking (model 1 = mID1–xxxx). Just don't be thinking you will also use this as you FM unique record identifier, as it is bound to fail you at some point.
ID = auto enter serial number ( next value 0001) for your relationships
Model = model name
modelAbbr = user input or calc from the model name
user viewable model ID = modelAbbr & ID
Absolutely agree with keywords that, if Unique ID is meant to serve as the table's primary key, then a separate field that is not exposed to users is preferable and considerably more robust. A lot of (most?) developers are using a UUID for that, either FM's native Get ( UUID) function or any of several custom functions that provide one. (For large tables, a strictly numeric version, which a custom function can provide, may yield a small performance benefit; most solutions, however, are unlikely to see that benefit in practice.)
Do you track any other attributes of each Model (or are you at all likely to do so in the future)? If so, then Model should probably be a separate table with its own primary key — again, a robust key such as a UUID, rather than "Model1," etc. — and represented in your table here by a matching foreign key. But I'm reading into your description well beyond what you've provided, and possibly incorrectly.
mark and keywords you both are correct. i'm thinking that that the UUID can be a meaningful use to users as an identifier; however, after reading both replies, i have to agree with what you both are alluding to. UUID cannot be used in the sense of keeping track of the different models of units, rather the UUIDs are useful for relationships between tables. i was thinking that UUID may be able in some way to be used as a tracking ID number of some sort. i greatly appreciate you both for really clarifying that up for me.
the next question would be: how would i go about adding an ID (text field) that can be used like an asset tag for the different models (which will be meaningful)? as stated in the OP, the the numbers will have to increment by 1.
i have never dealt with something like this before as it popped in my mind regarding these different models (of phones lol).
Have a look at this example.
I think what you're trying to do is create increments for grouped sets of data.
Therefore model should ideally be a separate entity, I gave it a separate table.
Is the field you're trying to calculate like an SKU = Stock Keeping Unit?
I was trying to write a lengthy post about uniqueness similarities between UUID and SKU but it's too complicated.
Let me know what you think.
serials.fmp12.zip 72.0 K
thank you keywords and electon, and, of course, everyone that replied. i apologize for not getting back to you all. work has been quite busy. being a trainer, we've been getting a lot of new faces. not just that, but vendor visits and audits, well, busy...lol.
appreciate all your replies, again. keywords and electon, i'll look at both of your files and see where i'll go from there. appreciate the sample files a lot.