For the following problem I am looking for the best practice.
We just currently found out that we have one employee in our database twice under different PK in our table as below which is connected to other table with FK_store_employee.
HR wants to consolidate his record under "Johnson" and move his code from 14 to 15.
This table has FK constraint to a table called "Store" which is below:
How I would like to approach to the solution is that ->
1) Replace employee_id 1 to 2 in store table.
2) Delete duplicates from store table
3) Delete primary key 1.
Is this this best approach? Can you give me any T-sql script sample to solve this with one run script?
Hello i have a question i assume mainly about SQL server functionality. Im building a test database and i have stumbled a problem when i try to insert data into my tables.
picture 1 shows the error message i get when trying to add rows.
https://i.stack.imgur.com/GW3C2.png
Picture 2 shows all relations in the database
//i.stack.imgur.com/7BhHa.png
picture 3 shows the table i am currently trying to update
//i.stack.imgur.com/3JqtA.png
In the table i have a combined primary key ("SDat" and "Kurs") The error message i get implyes that primary key must be uniqe, but what dont understand is since i have a third column "Elev" which makes the row uniqe, why wont SQL server me insert this row to table? I have tried making the same database in Acess and it works so i assume problem is something in SQL server
Regards Robert
A Primary Key by definition means the value must be unique. So if you have a combined primary key on 2 fields, then that value on those 2 fields needs to be unique meaning it can only have 1 row. If you need to enforce unique values on the combination of 3 fields (SDat, Kurs, and Elev) then your PK needs to include all 3 fields.
If you really need to enforce a unique constraint across alot of fields in a table, I wouldn't use a PK to enforce that, but instead use a UNIQUE constraint.
ALTER TABLE tablename ADD CONSTRAINT constraintname UNIQUE (column1, ..., columnn)
Then you can create a different column for your Primary Key so that as you add columns and need to require those additional columns be unique, you don't have to edit your PK and rebuild your table.
This question have been asked by several people but my problem seems to be different.
Actually I have to merge same structured tables from different databases in postgresql into a new DB. What I am doing is that I connect to remote db using dblink, reads that table in that db and insert it into the table in the current DB like below
INSERT INTO t_types_of_dementia SELECT * FROM dblink('host=localhost port=5432 dbname=snap-cadence password=xxxxxx', 'SELECT dementia_type, snapid FROM t_types_of_dementia') as x(dementia_type VARCHAR(256),snapid integer);
First time this query runs fine, but when I run it again or try to run it with some other remote database's table: it gives me this error
ERROR: duplicate key value violates unique constraint
"t_types_of_dementia_pkey"
I want that this new tables gets populated by entries of others tables from other dbs.
Some of the solutions proposed talks about sequence, but i am not using any
The structure of the table in current db is
CREATE TABLE t_types_of_dementia(
dementia_type VARCHAR(256),
snapid integer NOT NULL,
PRIMARY KEY (dementia_type,snapid)
);
P.S. There is a specific reason why both the columns are used as a primary key which may not be relevant in this discussion, because same issue happens in other tables where this is not the case.
As the error message tells you - you can not have two rows with the same value in the columns dementia_type, snapid since they need to be unique.
You have to make sure that the two databases has the same values for dementia_type, snapid.
A workaround would be to add a column to your table alter table t_types_of_dementia add column id serial generated always and use that as primary key instead of your current.
I need to make some changes to a SQL Server 2008 database.
This requires the creation of a new table, and inserting a foreign key in the new table that references the Primary key of an already existing table. So I want to set up a relationship between my new tblTwo, which references the primary key of tblOne.
However when I tried to do this (through SQL Server Management Studio) I got the following error:
The columns in table 'tblOne' do not
match an existing primary key or
UNIQUE constraint
I'm not really sure what this means, and I was wondering if there was any way around it?
It means that the primary key in tblOne hasn't been properly declared - you need to go to tblOne and add the PRIMARY KEY constraint back onto it.
If you're sure that tblOne does have a PRIMARY KEY constraint, then maybe there are multiple tblOne tables in your DB, belonging to different schemas, and your references clause in your FK constraint is picking the wrong one.
If there's a composite key (which your comment would indicate), then you have to include both columns in your foreign key reference also. Note that a table can't have multiple primary keys - but if it has a composite key, you'll see a key symbol next to each column that is part of the primary key.
If you have a composite key the order is important when creating a FK, and sometimes the order is not how it is displayed.
What I do is go to the Keys section of the table1 and select script primary key as create to clipboard and then create FK using the order as shown in script
I've had this situation that led me to this topic. Same error but another cause. Maybe it will help someone.
Table1
ColA (PK)
ColB (PK)
ColC
Table2
ID (PK)
ColA
COLB
When trying to create foreign key in Table2 I've choose values from combobox in reverse order
Table1.ColB = Table2.ColB
Table1.ColA = Table2.ColA
This was throwing me an error like in topic name. Creating FK keeping order of columns in Primary key table as they are, made error disappear.
Stupid, but.. :)
If you still get that error after you have followed all advice from the above answers and everything looks right.
One way to fix it is by Removing your Primary keys for both tables, Save, Refresh, and add them again.
Then try to add your relationship again.
This Error happened with me When I tried to add foreign key constraint starting from PrimaryKey Table
Simpy go to other table and and create this foreign key constraint from there (foreign key Table)
This issue caught me out, I was adding the relationship on the wrong table. So if you're trying to add a relationship in table A to table B, try adding the relationship in table B to table A.
That looks like you are trying to create a foreign key in tblTwo that does not match (or participate) with any primary key or unique index in tblOne.
Check this link on MSDN regarding it. Here you have another link with a practical case.
EDIT:
Answwering to your comment, I understand you mean there are 2 fields in the primary key (which makes it a composite). In SQL it is not possible to have 2 primary keys on the same table.
IMHO, a foreign key field should always refer to a single register in the referenced table (i.e. the whole primary key in your case). That means you need to put both fields of the tblOne primary key in tblTwo before creating the foreign key.
Anyway, I have investigated a bit over the Internet and it seems SQL Server 2008 (as some prior versions and other RDBMS) gives you the possibility to reference only part of the primary key as long as this part is a candidate key (Not Null and Unique) and you create an unique constraint on it.
I am not sure you can use that in your case, but check this link for more information on it.
I have found that the column names must match.
Example:
So if tblOne has id called categoryId a reference in tblTwo must also be called categoryId.
_tblname, primary key name, foreign key_
tblOne, "categoryId", none
tblTwo, "exampleId", "categoryId"
I noticed this when trying to create foreign key between 2 tables that both had the column name "id" as primary key.
If nothing helps, then this could be the reason:
Considering this case:
Table A:
Column 1 (Primary Key)
Column 2 (Primary Key)
Column 3
Column 4
Table B:
Column a (Primary Key)
Column b
Column c
when you are defining a dependency B to A, then you are forced to respect the order in which the primaries are defined.
That's mean your dependency should look like this:
Table A Table B
Column 1 Column b
Column 2 Column c
AND NOT:
Table A Table B
Column 2 Column c
Column 1 Column b
then this will lead to the error you are encountering.
I've found another way to get this error. This can also happen if you are trying to make a recursive foreign key (a foreign key to the primary key in the same table) in design view in SQL Management Studio. If you haven't yet saved the table with the primary key it will return this message. Simply save the table then it will allow you to create the foreign key.
If you have data in your tables this could be the issue.
In my case I had some data in the Account table that I loaded at 3 pm, and some data in Contact table that I loaded at 3:10 pm, so Contact table had some values that weren't in my Account table yet.
I ended up deleting these values from the contact table and then managed to add a key without any problems.
Kindly also see that there are no existing data inside the table where the primary key is defined while setting the foreign key with another table column.
this was the cause of the error in my case.
I had to take backup empty the table set the relationship and then upload the data back.
sharing my experience
Was using ms sql smss
What is the best way to translate the following problem in SQL table structure:
In a file transfer application, I have a master table with an "Upload type" field. Depending on the value of that field (FTP, SFTP, HTTPS, FS copy) the record is to be linked with other entries in the appropriate table (FTPsites, HTTPSSites, etc.) containing the relevant details.
This master table has several similar "switch" fields (upload, download, encryption, decryption, and a few application-related ones).
Currently, the table has a different field for each possible target table. This allows me to keep integrity constrains on the table but that's a lot of fields which are going to be NULL.
Is there a better schema for solving that problem ?
In case it's relevant, the target DB is MS SQL 2008
What you are describing is a database design issue akin to implementing table inheritance (where your master table is the parent and your type-specific tables are the children). You can see a really good explanation of how to implement table inheritance with SQL Server 2005/2008 here:
http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server
...but I will adapt the design pattern in that article to your specific case below.
First, you need a new table to hold your possible list of UploadTypes:
create table UploadType
(
UploadTypeID int primary key,
UploadTypeDesc varchar(50)
)
Now, make sure your MasterTable has a foreign key to the UploadType table and add an additional UNIQUE constraint to your master table on the fields MasterTableID and UploadTypeID:
create table MasterTable
(
MasterTableID int primary key,
UploadTypeID int references UploadType(UploadTypeID),
-- ...Other fields...
constraint MasterTable_AltPK unique (MasterTableID,UploadTypeID)
)
Assuming you have inserted values into the UploadType table so that HTTP uploads have an UploadTypeID = 1, FTP uploads have an UploadTypeID = 2, and SFTP uploads have an UploadTypeID = 3, you can set now up your upload-specific tables as follows (explanation at the end):
create table HTTPSites
(
HTTPSiteID int primary key,
UploadTypeID as 1 persisted, -- computed column; explanation below
-- ...Other fields...
foreign key (MasterTableID, UploadTypeID) references MasterTable(MasterTableID, UploadTypeID)
)
create table FTPSites
(
FTPSiteID int primary key,
UploadTypeID as 2 persisted,
-- ...Other fields...
foreign key (MasterTableID, UploadTypeID) references MasterTable(MasterTableID, UploadTypeID)
)
create table SFTPSites
(
SFTPSiteID int primary key,
UploadTypeID as 3 persisted,
-- ...Other fields...
foreign key (MasterTableID, UploadTypeID) references MasterTable(MasterTableID, UploadTypeID)
)
Each of these type-specific tables includes a dual-key foreign key to the master table on the MasterTableID and the UploadTypeID (this is how you get your referential integrity), and each includes a computed-column for the UploadTypeID that reflects the specific type of upload stored in that table. Each of these computed columns will force any new records inserted into these type-specific tables to be created with a specific UploadTypeID, therefore locking the tables to a specific upload type.
The beauty of this design is that it gives you database-driven referential constraints that meets all of your data integrity requirements without a lot of nulls. You can see the above posted article for detailed examples of how this schema prevents data integrity problems during inserts, deletes, etc. if you want to go deeper.