Updating fields on FMP Server

[Claus Pedersen]

I am running a serial number database in a major solution, running on FMP 5.0 server.

Problem is is that when users ask for a serial number in that database and increase the number by one, the field is not updated immediately. This may give two users the same number when accessing the field shortly after each other.

Is the any possibility of forcing the data update on the server?

As I am aware the "Flush Cache to Disc" does not work on servers?

------------------

[LiveOak]

I'll guess that you are using a single record database to store the serial number (not a global) and incrementing the field. I've not done a test to investigate how fast this is updated. I would think it would update as the record is released for use by another user and should not be a problem.

If you are using a global for storage, that is the problem. You don't give any details about how the serial number is stored, incremented, or what "ask for a serial number" means.

If you'll describe the operations more completely, there may be a clue. -bd

[This message has been edited by LiveOak (edited February 07, 2001).]

[Claus Pedersen]

Yes, the serial number database is a single record database, with different fields containing different serial numbers.

The lookup of the serial number happens from various bases that need the serial number.

They get the number by a relationship and increase the serial number in the same way:

gSerial = Serials:Invoice_serial

Serials:Invoice_serial=Serials:Invoice_serial+1

___

The update frequency on the server depends heavily on how busy the server is serving other clients. If it is very busy I've experienced more than 20 seconds until increament is updated.

And 20 secs is a long time with users constantly asking for various serials.

Hope this clarifies my question.

------------------

[Claus Pedersen]

Thanks for the advice.

However, the reason for having a serial number database is that I have 25-30 serial numbers.

If using auto enter serials, creating a new record will result in all numbers to be increased.

------------------

[DykstrL]

set up the serial number file with a text field to auto-enter the serial number.

Then set up an open script to create a new record, push the data to a global in the other file, then close the file. You should not have any duplicate serial numbers, even if users request a number "at the same time".

Also make sure the file is being opened (especially in your scripts) through the "Host" option and not through the directory structure - THAT can cause long access times.

[BobWeaver]

This is similar to a problem that I have been having for a very long time with a client's database. Unfortunately, I still haven't found a solution to it. You may want to try something along the lines of what I am now trying to setup.

code:

---

Set Error Capture On

Loop

Go to Field[ParkHere]

Exit Loop If [not (Status(CurrentError)=301)]

End Loop

Set Field[serNo, SerNo+1]

Set Field[gblSerNo, SerNo]

Exit Record/Request

---

where SerNo is the serial number field that gets incremented, gblSerNo is a global field, and ParkHere is any type of field. The idea is to make Filemaker lock the record by going to the ParkHere field. If another user has already locked the record, you will get an error 301 when you try to do it, and you will stay in the loop until the record is free. Then the set field will increment the serial number. The second Set Field step will set a global field to the same value. The key here is that each user has a separate copy of the global field. Once it is set, another user cannot corrupt your global. The last step exits the record, freeing it up for the next user. Finally, you can then use the gblSerNo field in your subsequent script steps and calculations.

Does this actually work? I don't know. I'm still setting things up on my system, and my problem is slightly different. Anyway, this may give you a few ideas.

[This message has been edited by BobWeaver (edited February 09, 2001).]