I am importing data from an access table to SQL. I have a primary key is SQL "quoteID" which obviously doesn't allow duplicates but I'm looking to add that requirement to another field.
Can't seem to find where to set that? perhaps it has to do with the field type??
You can require that a column be unique using a unique constraint or unique index:
alter table t add constraint unq_t_col unique (col);
or:
create unique index unq_t_col on t(col);
Make the field a primary key of the table. Or put an index on that field that enforces unique values.
Related
How do prevent a table with 2 FOREIGN key's from having repeated rows with the same value.
Thks in advance.
Use a unique index or constraint:
alter table example
add constraint unq_example_fk1_fk2 unique (fk1, fk2);
A unique constraint and unique index do essentially the same thing. So, you can also do:
create unique index unq_example_fk_fk on example(fk1, fk2);
Suppose user name and phone number should be unique at the time of table define without using unique constraint and check constraint in sql server.i don't want to create sp for that.please suggest any otherway to prevent duplicate column in sql server r2 2008. Il
One correct way (and really the best way) is to use a unique constraint. It is unclear whether you want one or two constraints, based on your description. If you don't want a unique constraint, you should explain why not.
That is, if you want the pair to be unique:
alter table add constraint unq_t_username_phonenumber unique (username, phonenumber);
Or you want each one to be unique:
alter table add constraint unq_t_username unique (username);
alter table add constraint unq_t_phonenumber unique (phonenumber);
When you define the table, you can also do one-column unique constraints in-line:
create table . . . (
. . .,
UserName varchar(255) not null unique,
. . .
);
Almost equivalent to a unique constraint is a unique index:
create unique index unq_t_username on t(username);
The difference is that you can name the constraint. This name is handy when a violation occurs, because the constraint name (but not index name) is typically in the message.
I have to insert data into a table that has a PK in it. I also have another table that has a clustered index in it.
Should I drop the PK or the INDEX for the the best INSERT speeds? Then recreate them afterwards?
I load data to these types of tables on a routine basis and I want to make sure I am using the quickest way possible in all situations.
A primary key uniquely identifies a record and has other uses as well. An index makes select queries run faster.
You should never drop your primary key.
Whether or not you drop and re-create indexes when adding records depends on the circumstances.
Primary Key : Uniquely identifies the the data & we cannot insert duplicate Data.
Index : Index help us to get out data to us very quickly.
Very Important Concept about Primary key & Index
Suppose your column is marked with the primary key then Clustered Index automatically gets created,
If no clutstered index is already present in the table
To See that Your Index is Created Successfully, You can use.
sp_helpindex Index_Name
- About Index :
You cannot create a unique index on a single column if that column contains NULL in more than one row. Similarly, you cannot create a unique index on multiple columns if the combination of columns contains NULL in more than one row. These are treated as duplicate values for indexing purposes.
- About Primary Key :
All columns defined within a PRIMARY KEY constraint must be defined as NOT NULL. If nullability is not specified, all columns participating in a PRIMARY KEY constraint have their nullability set to NOT NULL.
I would like to add an autoincrementing integer field called uid to an existing table assoc, but it doesn't look like I can do that unless it's a primary key.
I have fields local_id and remote_id which are the existing primary key pair, and I do that so that I can INSERT OR IGNORE INTO assoc so that I don't get duplicate primary keys, but if I have a pair of columns as a primary key, I can't seem to use them as an update (see other SO question).
Could anyone suggest how to restructure the table (and implement that restructuring using ALTER TABLE) so that I can get the behavior I need:
a single autoincrementing key, so I can use that for UPDATEs
a pair of fields local_id and remote_id so that the pair (local_id, remote_id) remains unique in the table
In this case, you could drop the primary key on your existing columns, create the new primary key integer autoincrementing column, then create a UNIQUE index on the other two columns.
Aha, I don't need to -- there's a builtin rowid column.
In SQL Server 2005+ (I use both), does adding the UNIQUE constraint to a column automatically create an index, or should I still CREATE INDEX?
See this MSDN article:
The Database Engine automatically
creates a UNIQUE index to enforce the
uniqueness requirement of the UNIQUE
constraint.
If you do create an index, you'll end up with two indexes, as this example demonstrates:
create table TestTable (id int)
alter table TestTable add constraint unique_id unique (id)
create unique index ix_TestTable_id on TestTable (id)
select * from sys.indexes where [object_id] = object_id('TestTable')
This will display two unique indexes on TestTable; and the HEAP that represents the table itself.
Yes, it does.
In fact, you can even create a CLUSTERED UNIQUE CONSTRAINT:
ALTER TABLE mytable ADD CONSTRAINT UX_mytable_col1 UNIQUE CLUSTERED (col1)
, which will make the table to be clustered on col1.
Almost all databases create an index for UNIQUE CONSTRAINT, otherwise it would be very hard to maintain it.
Oracle doesn't even distinguish between UNIQUE CONSTRAINT and UNIQUE INDEX: one command is just a synonym for another.
The only difference in Oracle is that a UNIQUE INDEX should have a user-supplied name, while a UNIQUE CONSTRAINT may be created with a system-generated name:
ALTER TABLE mytable MODIFY col1 UNIQUE
This will create an index called SYS_CXXXXXX.
An index is created when you add a unique constraint:
Reference -- see the second paragraph.
When a UNIQUE constraint is added to
an existing column or columns in the
table, by default, the Database Engine
examines the existing data in the
columns to make sure all values are
unique. If a UNIQUE constraint is
added to a column that has duplicated
values, the Database Engine returns an
error and does not add the constraint.
The Database Engine automatically
creates a UNIQUE index to enforce the
uniqueness requirement of the UNIQUE
constraint. Therefore, if an attempt
to insert a duplicate row is made, the
Database Engine returns an error
message that states the UNIQUE
constraint has been violated and does
not add the row to the table. Unless a
clustered index is explicitly
specified, a unique, nonclustered
index is created by default to enforce
the UNIQUE constraint.