Hey hey

If I'm running a database on a server which generates an invoice number as a serial number, how can I guarantee that another computer running the same database is not generating the same invoice number as me?

Also, what is the best way of running a database on a server without having to load the entire database on each computer which would slow down the system? I do have bridge files holding information but cannot think of a way of writing to an empty database which writes new records in another one on the server.

Cheers

I'm a little confused by your use of the term "server". If you are running, say, FM Server on a computer acting as a "server" for FM, you DON'T put copies of your files on other computers. The files are "served" by the "server" machine you have established. Otherwise, there is really no purpose to having a server, if everyone is really working off of their own local copy of the files.

I don't know what you mean by "bridge" files. Why would you want local files and then write to empty files on the server? I think you might have major confusion about how a server architecture works. With FM server, up to 250 users can share the SAME set of files and use them simultaneously.

-bd

What I mean by bridge file is, for example, a list of products that are written into a line entry database through a portal in an orders database. This file is all connected to the orders database by an order number but each item that is sold or ordered is an individual record in it's own database. The reason I use this is because it is very easy to do any form of search. Within a staff database I can use the same bridge file to find out what products were sold by which salesperson. Within a stock control database I can see exactly what has been sold item by item.

Each database updates this bridge file when a product is dispatched, returned, sold, commission paid, etc.

All I've done is allow creation of related records in the portal and made the related file lookup the order number each time a record is created. I then have different scripts which SET FIELD in related file to update stock, etc.

All the databases (Purchasing, Purchasing Bridge file, Orders, Stock Control, Staff, Orders Bridge File, Clients and suppliers.) will all be on a server which will be served by up to 45 computers at any one time.

The reason I have a purchasing and an orders bridge file is because one contains records of purely income, the other of outgoings. Each one can generate reports of profits and outgoings easily.

I hope this info proves more useful.

Thanks for reading all this drivell, my original question was -

If all the 45 computers load from the server the orders database, which generates it's own order number (serial number), how can I be sure that another computer hasn't created the same order number that I have by creating a new record?

Thanks

Whew, I thought your were headed down another path. It's clear if you are writing order/inventory applications that you are not confused about how client/server operates!

If you are using an auto entered serial number for your invoices, FM takes care of duplicates with built-in record locking logic. If you were grabbing a number under script control, adding one, and writing it back, it is possible to have a problem.

As to performance issues, one design decision that will be based upon the number of users and transactions is whether or not to dynamically add up the sales transactions to hot update the inventory quantity. It's nice to have an instantly accurate inventory quantity, but this related sum can be slow. An alternative is to keep a working count which is updated in the background every night.

-bd

Thanks for that - I just read the original message, that was long - sorry.

Am I correct in thinking, that what you do on one computer (eg. Find request) does not effect what another computer can see (hopefully all records)?

Yes, you are right:

while INSERT / UPDATE operations have side effect on the hosted files (then affect all the connected clients) the FIND / SORT operations have effect ONLY on the issuing client.

Nice jobs.