After your query runs, you'll have a set of copied rows (with configid=41
) and an identical set of pasted rows (except for the configid=76
and the auto-created id
).
Since, these ids are not known in advance, you'll need another way to identify rows of the config table, e.g. a unique key (besides the auto-incrementing one), so you can match (join) the newly created rows with the old ones.
If, for example, the (configid, optionname)
is unique, then the following would work:
INSERT INTO pricing
( relid, price, ... ) --- relid and all the other columns,
--- except any autoincrement you may have
SELECT pasted.id, p.price, .... --- and the same columns here
FROM
pricing AS p
JOIN
tblproductconfigoptionssub AS copied
ON copied.id = p.relid
AND copied.configid = 41
JOIN
tblproductconfigoptionssub AS pasted
ON pasted.optioname = copied.optioname
AND pasted.configid = 76 ;
primary key...will be the concatenation of two field values within the table.
no NO NO!!!!!
This breaks all the rules of database normalization (well, rule 1 and rule 2 actually) and it's totally unnecessary! It uses more storage, makes your queries less efficient, and may cause bugs in your processing.
Use the existing columns as the primary key.
Presumably it doesn't have a primary key declared already.
Check that you've got no duplicates in the table:
SELECT ContractNum, PlanId, COUNT(*)
FROM ContractPlans
GROUP BY ContractNum, PlanId
HAVING COUNT(*)>1;
Fix the data if you need to, then
ALTER TABLE ContractPlans
ADD PRIMARY KEY (ContractNum, PlanId);
Best Answer
You need to update the existing table.