Jump to content

Serial numbers not behaving serial


alopas

This topic is 6609 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi,

This is how the field is defined:

SerialField

Text

Auto-enter Serial, Serial number On creation, next value TRCV0500 increment by 1, Unique value

If in one machine the user creates a new record, then first gets TRCV0500, afterwards TRCV0501, etc.

Then, in another machine, the user creates a new record, and gets the message ""SerialField" is defined to contail unique values only. Allow this duplicate value?" (assigns again TRCV0500 instead of TRCV0503)

What am I missing here???

Thanks in advance

Link to comment
Share on other sites

I would use:

SerialField

Text

Auto-enter Serial, Serial number On creation, next value TRCV0500 increment by 1, Prohibit modification of value during data entry.

You don't need to validate for unique value.

How are these computers connected? Is there a FM Server? Are you using OS networking or FMP networking? Do both computers have a copy of the database?

Link to comment
Share on other sites

There are actually 23 computers accessing a FM Server 7 via "open remote" (server installed on an Xserve, clients are all Macs).

I can't use "Prohibit modification of value ..." because in some cases the user needs to change the value for this field. I can't use a random number either because the values have to follow certain sequence. Thank you very much for the tips though.

Anyway ... is this suppose to happen? Aren't serial numbers suppose to increase by 1 across the network???

I'm thinking that maybe the file is corrupt. I had another file that did some weird things: when I tried to define a calculation field, the calculation just wouldn't work (not even the simplest one), however the calculations that I had previously defined they all worked perfectly. Anyway, I took out the file from the FM server, I used the "recover" option, I put it back in the server, and now new calculations work ... B)

Thanks again

Link to comment
Share on other sites

Alopas:

It is possible that the file is corrupted. If so, do not do what you did with the other file you mentioned. When you use "recover," your best bet is to pull the data from the recovered file into a previously saved clone, because "recover" is there for you to recover your data - chances are there is still some corruption in the file itself.

Also, I don't understand how you've got a sequential serial number which users may then need to change. If you're going with a sequential number, you should stick with it. The reasons for this are obvious - if someone changes TRCV0502 to TRCV0503, what happens if the latter number already exists? If the users allows the non-unique value, what then?

-Stanley

Link to comment
Share on other sites

  • 3 weeks later...

Hi,

OK, it's working now blush.gif ... weird.

The reason why I can't stick to a unique serial# is because this is not a PK, so in a few cases the user needs to duplicate the record and change the value of a second field. These two fields together do make a composite key. Anyway ... thanks for your help!

Link to comment
Share on other sites

This topic is 6609 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.