Combination of two fields must be unique.

[Darren Bartrup]

I know if I set two fields as Primary Keys then the combination of those two fields cannot be duplicated within the table.
Is there a way of achieving this without setting the fields as Primary Keys?

I have a table with four fields:

ID	AutoNumber and PK
sPostalSector	Text
lBranchID	Number
lGroupName	Number

<tbody>
</tbody>

A combination of sPostalSector and lBranchID field cannot be duplicated.
As sPostalSector is text I'm pretty sure it's not the best idea to have it as part of a Primary Key.

Any help would be greatly appreciated.

 

[Joe4]

As sPostalSector is text I'm pretty sure it's not the best idea to have it as part of a Primary Key.

Why not? I use text fields as primary keys all the times (i.e. my client codes are often alphanumeric).
I have multi-field primary keys where both fields are text, and it works fine.

So using a mult-field primary key is certainly the easiest way. Otherwise, you may have to use VBA, and control all data entry through Forms.
Or try to figure out how to place Constraints on your tables/fields (easy in SQL, not so easy in Access). See: foreign key relationship - Uniqueness Constraints in MS Access - Stack Overflow

 

[xenou]

Also just to note, in the indexes dialog you can create any index:
How to create a composite unique index (not as a primary key) in MS Access
Create Table Index In Access 2010


For a composite index, you have to add the first row with the name of the index. Set the property value for the index to unique. In the row(s) below it, leave the name BLANK but continue to select any other fields that are part of the index, until you have all the fields included with the index, but the name of the index shown only in the first of those rows.

Agree that there's no real issue with making this a primary key - it should work either way. A primary key is basically a unique index, but it has the extra requirement that there be no null values.

 

[Darren Bartrup]

Thanks to both of you - I'll look into it. I've used Constraints before in MySQL (I think it was), but has been so long since I've built a database that I'm very rusty in anything other than fairly simple queries.
Need to get my books out again methinks.

Still haven't managed to test the code you gave me yesterday Xenou - will be after Easter now.

 

[Joe4]

So, based on all that we said, is there still some reason you don't want the use a multi-field primary key?

 

[Darren Bartrup]

Sorry for taking a few days - had to have a few days off to bask in the glory of a zombified son of a sky wizard.

So - no reason for not using a multi-field primary key, even if one of those is a text field. Problem solved, except I'm thinking of doing the back-end in MySQL now as our IT department will support that (I've always wondered what their definition of 'supporting' software is - I keep meaning to send them a spreadsheet and see if they can support anything more confusing than a simple VLOOKUP).

Thanks for the help and pointers.