Portals

[Violette]

I am creating a database for order entry. At the present time, I'm working on the packing list. Case scenario - the order we're shipping is not shipping complete, therefore a new p/s will need to be created from the same order to complete shipping same items. The problem is whenever I create a new packing slip with the same order number, the same information from the previous packing slip comes up on the new one, i.e. same quantity, code, and description. What do I need to do to make each packing slip unique to the same order?

[Kurt Knippel]

quote:

---

Originally posted by Violette:

I am creating a database for order entry. At the present time, I'm working on the packing list. Case scenario - the order we're shipping is not shipping complete, therefore a new p/s will need to be created from the same order to complete shipping same items. The problem is whenever I create a new packing slip with the same order number, the same information from the previous packing slip comes up on the new one, i.e. same quantity, code, and description. What do I need to do to make each packing slip unique to the same order?

---

Most likely you are using a number such as "packing slip" number as you ID field and using this for your relationships.

The best solution is to use some kind of unique ID that is not visible to the user nor used for anything that the solution is intended to do. You use this unique ID for relation these files together.

This way no matter what the Packing Slip number happens to be, you will be relating on a unique ID.

I use, and strongly advocate the use of, a text field with an auto-enter calculation such as the following: Status (CurrentRecordID) & "-" & Status (CurrentTime) & "-" & Status (CurrentDate).

This will give a number which, while not entirely random, is nearly impossible to duplicate without deliberate intent. Even then it is difficult.

DO NOT use the simple auto-entered serial number, or make this field a number. You will have additional problems later in life.

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

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Senior Filemaker Developer

http://www.inthescene.com

mailto:[email protected]

=-=-=-=-=-=-=-=-=-=-=-=-=

[markga]

Kurt, could you tell me why "...the simple auto-entered serial number, or make this field a number. You will have additional problems later in life" ??

Thanks!

[Kurt Knippel]

quote:

---

Originally posted by markga:

Kurt, could you tell me why "...the simple auto-entered serial number, or make this field a number. You will have additional problems later in life" ??

---

Which is more UNIQUE: 1 or A617697299072?

Which is more easy to duplicate accidentially?

Simple sequential serial number are highly problematic for IDs and this is the reason the no RDBMS uses a simple sequential serial number, nor do they use any value that the user has access to for IDs.

I recall the client who used phone numbers (they are all unique, right?) as IDs. Lots of people change phone numbers, oops where did all the invoices go? Phone numbers are NOT unique.

I recall the client who use social security numbers (they are all unique, right?) as IDs. Pretty soon they noticed related records popping up all over the place for multiple contacts. Social Security Numbers are NOT unique.

I recall the client who used a simple sequential NUMBER in all the IDs in a big system. Then they needed multikeys, but related records started popping up all over the place. Hmm, the database cannot distinguish between Contact #210 and Phone #210. Multiple #210s are NOT unique.

Bottom-line NEVER, EVER, NEVER, EVER use a simple sequential serial number or a user definable value as your ID. It is no more work for the RDMS to generate a complex, unique, non-random ID hidden from the user, than to create a simple sequential serial number. And it only takes a tiny bit of time on the developer's part.

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

=-=-=-=-=-=-=-=-=-=-=-=-=

Kurt Knippel

Senior Filemaker Developer

http://www.database-resources.com

mailto:[email protected]

=-=-=-=-=-=-=-=-=-=-=-=-=