Serial numbers not behaving serial

[alopas]

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

[RalphL]

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?

[dkemme]

Make sure the serial number is created upon creation, not upon commit. Many developers have utilized random number generators to avoid this problem.

[alopas]

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 ...

Thanks again

[stanley]

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

[RalphL]

If I remember correctly auto entered data is not subject to validation. I agree with Stanley that users should not be able to change this value.

[alopas]

Hi,

OK, it's working now ... 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!