Weapons Database Help

[ItsMe]

I just downloaded the DB and spent a few minutes on it. Considering June's comments, starting over is appropriate. It is likely you could still use parts of the reports (format). You could also use the existing DB to kinda help and understand the work flow.



After having some insight to the business rules, operations, and goals for data management, I would estimate a minimum of 72 billable hours over nearly three weeks time. This would be to launch a Beta. Afterwards, existing bugs would need to be fixed and there will be inevitable requests for added features or features that were not considered by the developer that should have been.

[cooglerj]

I'm trying to rebuild it but I'm at a loss on what to do

[burrina]

Without knowing your Schema it's impossible to design something. Anyway, here is a basic quickly thrown together BETA that maybe you could build on. I do NOT understand your db.Here is just a small gleaning of what I think it might start out to be. Maybe at the least, it will give you an idea. Good Luck!

HTH

[cooglerj]

Thanks alot for that. Ill see what I can do with it and let you know.

[cooglerj]

Quick question why when on the Main form when I try to open select a recruit it does nothing but makes an error sound?

[burrina]

By select, what do you mean? The Combo? Or the Search?

[cooglerj]

Also how would I go about assiging a weapon to a person. I get the same sound

[cooglerj]

Nermind figured the recruit part out.

[June7]

Assuming each person can have multiple weapons but each weapon can have only 1 person, enter person's ID into field of weapon record. Weapon is returned, remove ID from field.

Do you care about keeping history of weapon assignments?

[cooglerj]

No I dont care about history.

[cooglerj]

Also the defects and weapons codes dont really matter on this. If I could just enter thier name ,rank , weapons/weapons type issued with serial numbers and have that info auto fill into a form like this M16 NAVMC 10576.doc depeding on what weapon was issued would depend on the form it autofills. This one being for an M16

[cooglerj]

So I came up this. WEAPONSDATABASE.zip Basically what I want it to do is once I have searched or typed someones information into the form. I want the information to auto fill into different versions of this document M16 NAVMC 10576.doc to be printed on one page. I also need keep making a switchboard.

[ItsMe]

The DB in post #27 is neglecting basic principles of RDBMS. Having different tables for different weapons is not Normalized. Building forms and or reports before having a Normalized data structure is an exercise in futility.

The DB in post #18 may not be intuitive to you but, its tables employ Foreign Key fields to create relations. Tables need to be able to be JOINED on their relative Key fields.

Aside from all of the example DB's posted thus far, I understand you need to manage data that is inventory. To do this, you need a table that has records of your inventory. I recommend creating a single table that catalogs every unit and a single table that catalogs every part in your inventory. A unit would be a complete weapon and a part would be something like a lanyard, sling, or barrel.

Another need is to be able to check in and check out this inventory. You will need a table to keep track of these activities/events. In your events table, you will have a Primary Key field that serializes the action of an individual's request of issuance. In a typical business model, this is considered to be a Purchase Order or Work Order number. If there is ever a problem with the equipment related to a given purchase order, the PO number will act as a reference. If you look at a PO book in a mechanic's shop or a flower shop, you will notice that each PO has a number and each PO has a detail section. In order to provide details for your transaction at the armory, you will need a table of Details. This tblPO_Details will relate directly to tblPO. tblPO_Details will have a Foreign Key field to store the Primary Key value of the associated PO record.

If you look at that same PO from the mechanics shop you will see a header on the PO. In the header will be the Customer name and info. In order to relate this customer info you will need another table. Your Customers table will include information relative to each customer. It will have its own Primary Key field (Autonumber Type) and other fields/columns to describe the customers, fields like First Name, Last Name, etc. Your table of Customers would probably be more appropriately named tblMarines.

The structure would be similar to:

tblMarines
MarineID (Primary Key Autonumber)
MarineRank (Foreign Key Long Integer) another table with Rank info
EDIPI (Text)
FirstName (Text)
MiddleI (Text)
LastName (text)

Other tables will have similar structure of primary key fields and, if they need it, foreign key fields.