nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Data Deploy updating error.

dchristie

TS 6.5, DD 5.6

When DD does an update, we're getting a SQLException for a unique constraint error. I seems that when doing a look up that DD is querying all the columns and when it sees a column that doesn't match it fails whne trying to do an update.

Where do you define so that only the primary key is used for the record look up?

Find more posts tagged with

Comments

Adam Stoller

TS 6.5, DD 5.6

When DD does an update, we're getting a SQLException for a unique constraint error. I seems that when doing a look up that DD is querying all the columns and when it sees a column that doesn't match it fails whne trying to do an update.

Where do you define so that only the primary key is used for the record look up?

I don't believe you can - this is one of the pains of using DD, you have to accept that it's going to do things its way - if that doesn't work, you need to write your own DB interaction code (using perl, java, etc.)

vpatel

TS 6.5, DD 5.6

When DD does an update, we're getting a SQLException for a unique constraint error. I seems that when doing a look up that DD is querying all the columns and when it sees a column that doesn't match it fails whne trying to do an update.

Where do you define so that only the primary key is used for the record look up?

Based on the error *SQLException for a unique constraint error*, I would think that you are trying to insert multiple records with the same key. Have you validated that? Also keep in mind that if you have deployed DCR-A with primary key 101 and if you rename or move that DCR and try to re-deploy then it may throw this error as well. You'll have to deploy the deletion first for renamed / moved DCR from its previous location.

OutputSample.xls

dchristie

Based on the error *SQLException for a unique constraint error*, I would think that you are trying to insert multiple records with the same key. Have you validated that? Also keep in mind that if you have deployed DCR-A with primary key 101 and if you rename or move that DCR and try to re-deploy then it may throw this error as well. You'll have to deploy the deletion first for renamed / moved DCR from its previous location.

Well, this is an update to an existing record. So the primarky key, which is a content ID # stays the same, just other column fields will need to be udpated.

We had recently migrated the DB and TS server to another location. I'm wondering if this hasn't caused some type of disconnect from the DCR and their records in the DB?

vpatel

We had recently migrated the DB and TS server to another location. I'm wondering if this hasn't caused some type of disconnect from the DCR and their records in the DB?

Is the vpath for the particular DCR that you are testing the same or has it changed?

dchristie

Is the vpath for the particular DCR that you are testing the same or has it changed?

I do not think it has changed. The server and db were replicated in a remote environment for disaster recovery purposes. The box was mirrored as well as the db to my knowledge, but server addresses and domains all stayed the same. I did manually refresh the stores.

nipper

Are you using real updates or the default behavior ? You need to turn referential integrity off to use real updates.

sniv

Hey,

Do upload Deployment logs!

Regards!
Vinayak

jagadesh

post your deployment config and the record were you trying to deploy to DB?

Adam Stoller

I do not think it [vpath] has changed. The server and db were replicated in a remote environment for disaster recovery purposes. The box was mirrored as well as the db to my knowledge, but server addresses and domains all stayed the same. I did manually refresh the stores.

If you changed TS servers, then it is likely that the vpath may contain the server name (e.g.: //servername/default/main/...) and this would cause a discrepancy between old and new deployments.

dchristie

I've attached the deployment.cfg, a recent DCR and the corresponding DD log.

The V-path is the same since the migration we did kept everthing equal. All server ip's, paths, domains stayed the same.

dchristie

Are you using real updates or the default behavior ? You need to turn referential integrity off to use real updates.

I believe we are using real updates. I'm no dba, but where do you select referential integrity? At the db or DD?

vpatel

I believe we are using real updates. I'm no dba, but where do you select referential integrity? At the db or DD?

You don't need to be DBA in this case to find out whether you are using real updates or not. Look in your DD config file.

Adam Stoller

I've attached the deployment.cfg, a recent DCR and the corresponding DD log.

The V-path is the same since the migration we did kept everthing equal. All server ip's, paths, domains stayed the same.

We had recently migrated the DB and TS server to another location.

So you're saying that before, and after, the migration of the server - the server name was: ken-inwprd01.corp.interval-intl.com

If so, there shouldn't be any change in vpath - but if any part of the hostname changed, that could account for some of the issues - you'll probably need to dump the contents of some of the DB tables - including the IWOV_DELTRACKER table (or whatever it's called) to verify that the old and new data lines up correctly.

jagadesh

just check with your iwdeltracker contains the value for Content_id as the records were in offer_content table.

Temporary solution.
Insert row in iwdeltracker
Delete the values from offer_content then try the deployment again