Composite Key

[Swift_74d]

Hey all,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" /><o></o>
Just started to go back and review one of my first databases and correct allot of errors I made with the limited knowledge I had at the time.<o></o>
<o></o>
One of the biggest errors I made was not normalizing the data and, in an attempt to correct this error, I came across a table that got me kind of confused. This table ("Payments") doesn't have a Primary Key and I can't seem to find a composite key that would work.

Should i just add another field as an auto number to represent the primary key just to appease the rules, or are there exceptions to the rule and is this one of them? If anyone has any suggestions (table format is below) please let me know.<o></o>
<o></o>
The table is used to capture all payments made in respect to claims in the database in order to allow totals based on several different criteria.<o></o>
<o></o>
ID (Foreign Key)<o></o>
Month (In digit form)<o></o>
Year <o></o>
Payable to (Who the payment is going to)<o></o>
Amount<o></o>
Type of Payment (Handling / Settlement / General Payment)<o></o>
Company (Company Making the Payment)<o></o>
<o></o>
*Notes-<o></o>
Not the actual names of the fields just used plain words for ease of understanding.<o></o>
<o></o>
However improbable, it is possible for all fields in two records to be identical.<o></o>

 

[boblarson]

I would just add an autonumber and then, if you have to ensure that no duplicates are entered, instead of a composite key you can use a multi-field index. See here for how to set one up:
http://www.btabdevelopment.com/ts/mfi

 

[Norie]

Not sure how using an AutoNumber would 'appease' the rules but it's probably the best option.

Using composite keys is hard enough at the best of times and from what I've seen of your setup so far nothing immediately stands out that could be used for one.

Perhaps there's something in the data you could use?

 

[Swift_74d]

Thing is, i don't neccesarily want to prevent duplicate entries. There are rare times where all fields will be identical and not be incorrect. Plus these reports are produced as support for an account only used in claim payments (ie if the balance this month is x, what payments were made to bring it to x?) so if there are errored entries they stand out and are easily corrected (currently have payment entry set up with sub form showing the claim payment table to easily sort and correct).

I guess now my next question would be why set up an auto number if all its there to do is create another field that's only purpose is to say that there's a primary key?

 

[boblarson]

I guess now my next question would be why set up an auto number if all its there to do is create another field that's only purpose is to say that there's a primary key?

Because if you ever migrate this to SQL Server then it will require a key. Other than that, there probably is no reason.