CritterID is a data field that not only is a primary key, but also a number which automatically increments itself for each new record. Each CritterID will be unique and always counting forwards.

There may be situations where you delete a Critter, so CritterID may not always be one number after the other. So a CritterID of 13 may not be the 13th record in the database if Critters before it got deleted. It just holds a value of 13, which is unique to that Critter record. No other Criter may have that CritterID of 13, and CritterID cannot be blank or nothing, it has to be a valid number. These are characteristics of a Primary Key with an AutoNumber property. Some databases call the AutoNumber an Identity, it is basically the same thing.

You can later create a CritterShelf table having a ShelfID, and a CritterID field that goes back to the Critter table and ShelfID going back to Shelf. Matching the CritterID in CritterShelf to a CritterID in Critters will tell you which Shelf the Critter is on. This is called a Foreign Key, also may be called an External Key. When you place a Critter on a shelf, you have the database copy the CritterID from Critter and put it into CritterShelf using the correct ShelfID and the CritterID of the Critter you are moving. Critter and CritterShelf tables are linked by CritterID in both tables. CritterID is an Autonumber in Critter, but not in CritterShelf. This is because CritterShelf holds a copy of CritterID and doesn't need the AutoNumber property. It has to match a CritterID in Critter. It is Indexed, but not a Primary Key in CritterShelf, because it is a Foreign Key pointing to Critter and CritterID in that table.

If you enforce Referencial Integrity between Critter and CritterShelf, then when you delete a Critter, the matching record in CritterShelf gets deleted too for that CritterID you are deleting. Because if you get rid of a critter it no longer is on a shelf.

As was stated there is a Demo database called Northwinds. It comes with Access and you might have to install it from the setup to get it. Complete database for a fictacious company called Northwinds that Microsoft made as an example.

If I still had Access 97 installed, I'd create a database for you to use that was a lot simpler. I have Access 2000 and Access 97 cannot read that format.

Some things to remember:

Columns are pieces of information in a table. Think of the database as a Spreadsheet, in a Spreadsheet you store your data in Columns going left to right on the Spreadsheet. In a way Excel is like a database too. On Column "A" on your spreadsheet is Sales, on Column "B" is Quanity, and in Column "C" is the Customer Name who bought it. Each line in the spreadsheet is a number, goes for 101 rows. A1 contains the name "Sales", B1 contains the name "Quanity", and C1 contains the name "Customer". You might say that these are the names of the columns. A2 to A101 contains all of the sales, and look, the quantiy of the sales is in the same row number as the amount of the sales and customer name too. So B2 to B101 has the Quanity, and C2 to C101 has the Customer name. We can make a D column for total sales and make it equal to A times B, so D2 would equal A2 times B2, etc.

Ok now you know how a Spreadsheet database works. Let's create a database in Access. We have three columns, "Sales", "Quanity", and "Customer". Access is a little more picky than Excel and wants you to create the definition of these columns in a table. We just have to pick the right data type.

So we start up Access, it asks us which file to open, we'll choose "Blank Database" name it Sales.mdb, save it in C:\\DATA\\ so we can load it later. Mdb is the file extension Access uses for databases, Microsoft Data Base. Ok you should have a Window that says "Database" on it. Make sure that you've selected "Tables" on it, this is where we shall store our data in column names. But first we must create the table so Access knows where to put it. Click on the "New" button. The "New Table" window pops up. Click on "Design View" because we want to design a table. Now click on the "OK" button. Now you should see a grid that looks a bit like a spreadsheet. "Field Name" is the column name for the item in the table, "Data Type" is the type of data we want to store, and of course comments are there for in case we forget what we are using this for later.
Ok on the first row, enter "Sales" for the "Field Name", Click on Data Type it should have a drop down box. Pick "Number" because we are dealing with numbers here. Notice at the bottom of the Window that a "General" tab appeared and shows more info. Access wants to know what specific number we want to store. It defaults to Long Integers, but sales are in dollar amounts. It can have cents, so we want a decimal place, which rules out Integers. We need real numbers, either a Single or Double. Double is needed in case sales are really large numbers. So on "Field Size" click on the box and select "Double". Ok we created the first Column, seems easy enough. Now we need to do the same thing for Quanity and Customer. So click on the next row, and under "Field Name" put Quanity. For "Data Type" choose Long Integer because quanities are not fractions, and someone could make a huge purchase. Next row, under "Field Name" put "Customer", and in "Data Type" put "Text" because a customer's name is text after all. Under "Field Size" see that it defaults to 50, maybe someone has a long name, let's make it 100. Ok at this point you can either hit the "Diskette" looking button to save, or do a "File" menu and choose "Save" or Control-S, whatever floats your boat. Save the table. You should see a "Save As" window, it asks for a name. Let's give it one, name it "Orders". Ok now Access is squaking about no Primary Key is defined, don't panic, it isn't needed in this example. We can always add one later when we link up tables, but that is for a more advanced lession. So answer "no" and save it. Ok now close out the table window that has our definition on it, we just saved it. Now in the "Database" window you should see a table named "Orders". We've just created it. You can open it by double clicking on it, and then enter the data directly into the table. You can enter some values if you want, not really important.

Now let's go to Excel and create an Orders.xls spreadsheet.

Run Excel, in a blank spreadsheet type into A1 the word "Sales", B1 the word
"Quanity", and in C1 the word "Customer". Now in A2 enter a number, in B2 enter another number, and in C2 a name. Repeat this for however long you want to do it, you are now entering data into an Excel spreadsheet. After you are done we can import this Spreadsheet into our Access table easy peasy. Save the file as "C:\\Data\\Orders.xls". Go back to Access.

Ok in Access load the orders.mdb file. Under "File" choose "Get External Data" and then choose "Import", Access 97 may be different I am using Access 2000 here and it is set up like that. If that isn't it, look around for an "Import" or "Get External Data" command from the other menus. Ok once you've found the "Import" command, it will ask you for a file type. Choose "Microsoft Excel *.xls" and then select C:\\Data\\Orders.xls now it will ask you about Worksheets and how they are arranged. Choose "Show Worksheet" and chose "Sheet1". It should show sample data. Sales first, followed by Quanity, and then Customer. Don't worry that the field names are in the data columns, we'll fix that on the next step. Click "Next". It will ask if the first row contains field names, click on that box that this is true. It will then index the data by those names. Click "Next". "Where would you like to store your data?" it asks. New Table or Existing one. Choose "Existing One" and from the drop down box choose "Orders". Click "Next". The Wizard will now verify that you want to put the data into the table named "Orders". Click "Finish". It should say "Finished Importing file 'C:\\data\\orders.xls' into table 'Orders'". Click "OK".

Now if that works, you can double click on the Orders table and see that the data is there. If so, you've just merged an Excel spreadsheet into an Access table. Wasn't so hard now was it?

Some Access tutorials:
[link|http://www.bcschools.net/staff/AccessHelp.htm|http://www.bcschools...ff/AccessHelp.htm]
[link|http://cisnet.baruch.cuny.edu/holowczak/classes/2200/access/accessall.html|http://cisnet.baruch...ss/accessall.html]
[link|http://isds.bus.lsu.edu/cvoc/learn/introit/access/|http://isds.bus.lsu....n/introit/access/]
[link|http://www.todayskills.com/msaccesstutor/msaccess.htm|http://www.todayskil...utor/msaccess.htm]
[link|http://www.aotcomputers.com/microsoft-access-up.html|http://www.aotcomput...ft-access-up.html]
[link|http://computer-training.8m.com/microsoft-access-up.html|http://computer-trai...ft-access-up.html]

I kept the example as simple as possible. Enough to teach you the basics of creating a table and importing without getting into advanced topics like indexes, primary keys, and autonumber fields. It may be a poor table design, but it is easy to understand and simple for training purposes. John will be able to help if he's done Access before. Many Windows programmers have some experience with Access.

see, it wasn't that difficult. Now imagine you have to do that a dozen times a day or more. You are now just starting to understand, and getting ready in case they do hire you. Now you can tell her that you imported data into Access and know how to do it, and be honest about it. I'm proud of you.

she should copy the database file to a different name, and then work on the copy. That would be easier than learning how Access can back up tables. That way she won't lose anything, or have to learn something complex until later.