I have a project that I am working on where we have to create a registration system for a university in Access. One of the tables requires a surrogate key for one of the fields, and I am not sure how I can create a surrogate key.
The column instructions look like this:
Field Name Data Type Field Size Caption Format Req'd Index Unique Key Ref. Table Other
FacultyID Text 4 blank blank Yes Yes Primary blank Input Mask '0000;1;_'
FirstName Text 32 blank blank Yes No Surrogate* blank blank
So the first field, FacultyID is straightforward and simple to make. But the FirstName field requires a surrogate key that I do not know how to make.
It also has the asterisk next to it, and at the bottom of the page the asterisk reads:
*Index [LastName], [FirstName]: Duplicates Allowed (surrogate key)
The LastName field is listed later but I didn't show it in my question. What confuses me with this, however, is that in the column instructions, it says that the Index field should be No for FirstName, but this note at the bottom of the page makes it seem like it should be Yes (Duplicates OK) and I do not know what to put.
So can anyone help me figure out how to make the FirstName a Surrogate Key, and also what I should be putting in the Index field?
You'd need to post more info (like, is there an employees table?), but it looks like the instructions want you to use an employee's last and first name's as a composite key vs. surrogate. When designing a table, you can hold SHIFT + the fields you want to include in your key:
Then press the Primary Key button in the Tools section at the top:
And you'll end up with a composite primary key:
I think the wording on your requirements sheet is a little wonky. I think the only way to get a LastName, FirstName column is via some sort of Data Macro or through an append query.
Also, even if you don't use it for anything, I would suggest ALWAYS having an AutoNumber ID field. I've had database integrity issues when not having a key on each table.
But, without seeing the full assignment sheet, I would be tough to dial-in what you needed specifically.
Related
I was wondering if there is a way for a form to not generate a Primary Key as soon as I start typing on a field (this is just in case I don't really want to insert)? Can it show what Primary Key will be generated when I do/only generate and insert in the table?
There is a difference between a Primary Key and a automatically generated number. It is true that Access proposes an autonumber field as a PK, but you can definitely switch it to a number or character field. Then, you will have to find a way to enter manually the PK value, or generate it through code(*), before inserting the record in the table.
(*) In case you are using numbers as PKs, the logic could be here to check the higher PK value already in the table (max()) and add 1 to it.
I have a table that does not require a primary key. It consists of 4 columns which are email,date,time,message. Each time a user logs in, logs out, or does any particular action that is important, I log the email, date, time and action (message). Currently the table is setup with email as the Primary Key but I am unable to insert more than one record with the same email. I suppose I could use time as the PK but there is the possibility that two actions fall on the same time. How can I just use the table without a PK? I have tried turning it off for the email column but it does not allow me to.
Yes as you have defined email field as your primary, it can hold unique data only and no duplication allowed.
So you have two options:
1: Remove email field as a primary key
2: Add new integer field as a Primary key with auto increment (I would prefer this one)
You could use a natural primary key that would be a combination of Email + Date + Time + Action. That combination would be unique. It is impossible for the same user to do 2 different actions at the same time. That will help you to keep integrity of your information.
Hope this helps you.
To make a decision on a table' primary key one may start with considering these points (applicable to innodb):
How the data is going to be accessed after it is written (if you don't query it, why store it?). If you care about read performance you should query your data by the primary key, since for innodb primary key is the only possible clustered index.
The data is stored ordered by the primary key, so if you care about write performance, you should write data ideally ordered by your primary key, which always happens automatically if you have an auto_increment. Also table for which you don't explicitly specify a primary key are going to have a hidden auto_increment field which you won't be able to access, i.e. you get less for the same cost.
I have decided to set combination of three values as a primary key(composite key) for my database table.Most of the times the first two columns will be unique.But in a few cases they are both same at which time the third columns value will be always unique for that row.The problem is that the third column is a description which is any string that the user can enter.I know it is not recommended to have a user given string as a primary key.But is it okay to have it as a part of the composite key.I really see no other option.
If at all possible, you should add a surrogate primary key, meaning a key that is unique and has no business meaning whatsoever.
Composite primary keys very often turn out to be less 'stable' than anticipated - but if you MUST use one, using one or more component columns over which the user has little or no control (like created_timestamp) would be preferable.
Add a separate column called id and make it auto increment and use this column as a primary key.
Hope this will solve your problem.
Cheers.
I have two tables, the first one is called BOOKSNAME and the second is called AUTHORNAME.
I have made the ID column for the BOOKSNAME table as the primary key (BIGINT auto increment) then my AUTHORNAME table has NAME and ADDRESS as it's columns but I have no ID/Primary key on this.
I want to make a relation between them by primary key, if anyone has an example of how this is achieved, could they share it?
What you need to do is add a new column to your AUTHORNAME table called AuthorID or something similar, you can select 'Primary' on a drop down list under the INDEX when adding a new column to your table, and you also want to tick the A_I box (auto increment).
If you are unsure how to add a new column, follow these steps:
Firstly go to your phpmyadmin, and select the table in which you need to add this new column/ primary key to, and select the structure tab.
Here you will see the current column headings that your table already has, so from here you want to look towards the bottom of that list of columns where it will display options on how to add a new column to your table.
Ideally, you want to add the ID at the beginning of the table, as it will make it look far more structured and easier to read.
From here you want to enter the name of the column, in your case AuthorID, the type will be an INT, and you will want to make your index as PRIMARY, then lastly you will need to tick the A_I / Auto increment box (This may appear differently depending on what version of phpmyadmin you are running).
If you then want to make relations between the two tables, you can use something called JOINS, if you do a simple Google search, you can find many guides on how these are carried out.
Also add integer primary key to the author table, next you can have author_id field to another table, which is same datatype as authors table primary key, and store author id to that field.
Also if you use Innodb engine you can add foreign key constraint, it is very useful, for more see documentation: http://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
I am new to MSAccess so I'm not sure about this; do I have to have a primary key for every single table in my database? I have one table which looks something like this:
(http://i108.photobucket.com/albums/n32/lurker3345/ACCESSHELP.png?t=1382688844)
In this case, every field/column has a repeating term. I have tried assigning the primary key to every field but it returns with an error saying that there is a repeated field.
How do I go about this?
Strictly speaking, Yes, every row in a relational database should have a Primary Key (a unique identifier). If doing quick-and-dirty work, you may be able to get away without one.
Internal Tracking ID
Some database generate a primary key under-the-covers if you do not assign one explicitly. Every database needs some way to internally track each row.
Natural Key
A natural key is an existing field with meaningful data that happens to identify each row uniquely. For example, if you were tracking people assigned to teams, you might have an "employee_id" column on the "person" table.
Surrogate Key
A surrogate key is an extra column you add to a table, just to assign an arbitrary value as the unique identifier. You might assign a serial number (1, 2, 3, …), or a UUID if your database (such as Postgres) supports that data type. Assigning a serial number or UUID is so common that nearly every database engine provides a built-in facility to help you automatically create such a value and assign to new rows.
My Advice
In my experience, any serious long-term project should always use a surrogate key because every natural key I've ever been tempted to use eventually changes. People change their names (get married, etc.). Employee IDs change when company gets acquired by another.
If, on the other hand, you are doing a quick-and-dirty job, such as analyzing a single batch of data to produce a chart once and never again, and your data happens to have a natural key then use it. Beware: One-time jobs often have a way of becoming recurring jobs.
Further advice… When importing data from a source outside your control, assign your own identifier even if the import contains a candidate key.
Composite Key
Some database engines offer a composite key feature, also called compound key, where two or more columns in the table are combined to create a single value which once combined should prove unique. For example, in a "person" table, "first_name" and "last_name", and "phone_number" fields might be unique when considered together. Unless two people married and sharing the same home phone number while also happening to each be named "Alex" with a shared last name! Because of such collisions as well as the tendency for meaningful data to change and also the overhead of calculating such combined values, it is advisable to stick with simple (single-column) keys unless you have a special situation.
If the data doesn't naturally have a unique field to use as the primary key, add an auto-generated integer column called "Id" or similar.
Read the "how to organize my data" section of this page:
http://www.htmlgoodies.com/primers/database/article.php/3478051
This page shows you how to create one (under "add an autonumber primary key"):
http://office.microsoft.com/en-gb/access-help/create-or-remove-a-primary-key-HA010014099.aspx
In you use a DataAdapter and a Currency Manager, your tables must have a primary key in order to push updates, additions and deletions back to the database. Otherwise, they will not register and you will receive an error.
I lost one week figuring that one out until I added this to the Try-Catch-End Try block: MsgBox(er.ToString) which mentioned "key". From there, I figured it out.
(NB : Having a primary key was not a requisite in VB6)
Not having a primary key usually means your data is poorly structured. However, it looks like you're dealing with summary/aggregate data there, so it's probably doesn't matter.