Hello,

I am trying to figure out how to setup my tables. The tracking system i am trying to create will have these information:
the Tables will contain these information

- Package number
- Received date
- Sent date
- How long have we had the package
- Status (Sent or Pending)

I will also need to figure out who received and sent the package
- Employee name

Please advise if I setup the tables correctly.

I will also need to query these info:
- all packages received 3 days ago
- how many packages an employee received and sent
- How many sent or pending

Thank you for your help.

The tracking system i am trying to create will have these information:
the Tables will contain these information

- Package number
- Received date
- Sent date
- How long have we had the package
- Status (Sent or Pending)The length of storage time would be a calculated field, so that information should not be in your table. You should set up a query that holds the expression for the calculation, which will automatically populate the data when it is run.I will also need to figure out who received and sent the package
- Employee nameThis field should be a field in the "package info" table as well.

You could almost run this entire database from one table, but in order to normalize your data, and properly prepare for the expansion of the data warehousing, you should probably set up your primary tables (if applicable)...

**Employees
**Customers (recipients?)
**Distributors

All of those tables, if applicable, would contain primary keys, and would all be linked to an "orders" table, which would ideally hold all of the information that is listed at the top here.I will also need to query these info:
- all packages received 3 days ago
- how many packages an employee received and sent
- How many sent or pendingThis should be simple regardless of how you set up your structure. The only thing you need to know how to do to for this is navigate through the query grid.

A few helpful hints/ideas on **Normalization**
1) The concept of it is wonderful, and was very well thought out, but it is usually not necessary for a database to run properly.
2) It has many more uses and comes in handy more often when working with very large databases. People handling very small database files will find it less useful, but that is not to say that its presence is not as equally important in those files.
3) The best part about using the concept is the amount of time that is saved when trying to maintain a database. Another good part about it is the "big picture" you get of all your data. I can provide you with all the "little pictures" that make up the big one, which can give you a better understanding of your work in general.

These ideas are, of course, just my opinions, but, in my opinion, they are worth some thought, regardless of what the future holds for your database.

Thank you for your help. You make it sound really easy. I am new to access and trying to learn.

So if it's okay to combine those information on one table?

I actually plan on using a form that is going to be user friendly and more attractive.

The form will first ask for the Package number, once located, it will try to associate the package number with the processor (Employee), then the date received, and the status.

The query section will calculate how old the package is.
it will calculate anything past
- 3 days
- 10 days
- 30 days or more
- who processed it
- Status, whether pending or complete

THank you,


John

Thank you for your help. You make it sound really easy.That's because it is easy John! :DSo if it's okay to combine those information on one table?Yes, it is OK, but if you're planning to expand this file, it may be best to start with any kind of normalization you can get out of it. As for the rest of the information in your last post:

I understand what you want to do, but giving advice on that right now is irrelevant, because you don't even have a setup to go off of yet. Try giving it (the setup) a go on your own, and when you get stuck, then give us a holler.



If it helps you, this is how I would approach the setup (if I were doing this)...

1) Table w/Package info (Receipt Employee, package number, rec' date, scheduled departure, status, other relevant fields

2) Table w/employee info (serves as a lookup table for any search form controls or data entry/modification forms)

3) Other tables to hold primary information (carriers, customer, etc...) - Serves the same purpose as the table in #2

4) Calculations to be listed only in forms controls on each record presented (unless they are to be reported using the report object - then use the query to calculate and list records with calculations included). Calculated upon the push of a button. Process uses a combination of .Visible (property), DateDiff (function) & simple arithmetic (expression).

Note: Number 4 is a preference for me. I tend to hide data until it is actually needed, or relevant, and I use the .visible and .enabled properties frequently. I am known for writing code in which I give the information at the time it is needed, and when that time has expired, take it away. Example - OnClick of a button, calculate the difference between two dates, and set property of txtbox to .visible = true. On switch to next record, set visible to false. The button here, for me, would say something like, "Show me the elapsed time". That way, a user gets just what they ask for, and not much else. One way or another, they'll learn to appreciate that. :D :D

That's because it is easy John! :DYes, it is OK, but if you're planning to expand this file, it may be best to start with any kind of normalization you can get out of it. As for the rest of the information in your last post:

I understand what you want to do, but giving advice on that right now is irrelevant, because you don't even have a setup to go off of yet. Try giving it (the setup) a go on your own, and when you get stuck, then give us a holler.



If it helps you, this is how I would approach the setup (if I were doing this)...

1) Table w/Package info (Receipt Employee, package number, rec' date, scheduled departure, status, other relevant fields

2) Table w/employee info (serves as a lookup table for any search form controls or data entry/modification forms)

3) Other tables to hold primary information (carriers, customer, etc...) - Serves the same purpose as the table in #2

4) Calculations to be listed only in forms controls on each record presented (unless they are to be reported using the report object - then use the query to calculate and list records with calculations included). Calculated upon the push of a button. Process uses a combination of .Visible (property), DateDiff (function) & simple arithmetic (expression).

I will give this a try. I will definitely be coming back here if I get stuck and I know I will.

Thank you again for you help.

It's best to give it a try first Cooh. People here (I think!) are glad to give you some pointers, but you gotta take the first step!

(BTW, I added a note to my previous post you may not have seen...)

It's best to give it a try first Cooh. People here (I think!) are glad to give you some pointers, but you gotta take the first step!

(BTW, I added a note to my previous post you may not have seen...)

Thanks for the pointers. That's exactly how I want my database to do. :D

Yes, it is OK, but if you're planning to expand this file, it may be best to start with any kind of normalization you can get out of it.

Absolutely agree with this point. Have a "play" with different methods of achieving the same results by all means if you're still finding your feet in Access, but at the point you start making your real application, the more you get right in the beginning, the easier it will be both to maintain on an ongoing basis and to expand it's capabilities when, hopefully, your bosses think it's wonderful and want to add more stuff to it.

Absolutely agree with this point. Have a "play" with different methods of achieving the same results by all means if you're still finding your feet in Access, but at the point you start making your real application, the more you get right in the beginning, the easier it will be both to maintain on an ongoing basis and to expand it's capabilities when, hopefully, your bosses think it's wonderful and want to add more stuff to it.

I will be going this route. Thank you.