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; } } }

Records getting replaced in data deploy

InterwovenIsFun

I am deploying metadata from teamsite to database. In some cases, a new row is replacing an already present row in the table,even though the primary keys are different.

i have the following attributes for my database: update-type="standalone" state-field="state" delete-tracker="yes" enforce-ri="no". The real-update attribute ia also not set.

can anyone please guide me on this?

Find more posts tagged with

Comments

ruthieballenger

What does your IWDELTRACKER keys look like? Do your logs have the SQL used to select from IWDELTRACKER then find the data in the database?

Such as SELECT KEYCOLNAME , KEYCOLVALUE FROM IWDELTRACKER WHERE PATH = ? AND AREA = ? AND KEYCOLNAME IN ( 'KEYFIELD') Then right below that you should see those keys being selected from the tables using those key fields.
Such as
SELECT ALL_MY_FIELDS WHERE KEYCOLNAME = KEYCOLVALUE, etc.

dinaish20

What does your IWDELTRACKER keys look like? Do your logs have the SQL used to select from IWDELTRACKER then find the data in the database?

Such as SELECT KEYCOLNAME , KEYCOLVALUE FROM IWDELTRACKER WHERE PATH = ? AND AREA = ? AND KEYCOLNAME IN ( 'KEYFIELD') Then right below that you should see those keys being selected from the tables using those key fields.
Such as
SELECT ALL_MY_FIELDS WHERE KEYCOLNAME = KEYCOLVALUE, etc.

Hi
Sorry it looks like an old post, but this is the only relevant post I can find related to the query I have.

Can any one help me in pointing how to disable this behavior.
We are using OD 6.2.X with TS6.7.2.
What we need is data deploy should always insert into DB, it should not delete the old record using IWDELTRACKER.
Any pointers?

Thanks in advance.
Dinaish20

Rick Poulin

As long as you use different PK values and deploy files with different names, that's exactly the behaviour you'll get. Since you can't have two rows in a table with the same PK anyway, is there a reason why you need to keep the filename of different records the same?

dinaish20

As long as you use different PK values and deploy files with different names, that's exactly the behaviour you'll get. Since you can't have two rows in a table with the same PK anyway, is there a reason why you need to keep the filename of different records the same?

Hi
It is not two different records, it is the same record which I am redeploying multiple times. We have combination of time-stamp and product id as PKs but still old entry gets deleted from DB.

We have some requirement to have a history of updates related to every single DCR in DB.

Adam Stoller

Hi
It is not two different records, it is the same record which I am redeploying multiple times. We have combination of time-stamp and product id as PKs but still old entry gets deleted from DB.

We have some requirement to have a history of updates related to every single DCR in DB.

While that seems like a questionable requirement - if DD is overwriting the entry it probably means you didn't properly configure DD and/or the DB to understand about the multiple primary keys.

dinaish20

While that seems like a questionable requirement - if DD is overwriting the entry it probably means you didn't properly configure DD and/or the DB to understand about the multiple primary keys.

Thanks for the reply.
Attaching the DD. Please find for the string CMS_OVERLAY.
DB looks fine to me. So only DD can be the issue.

Adam Stoller

Thanks for the reply.
Attaching the DD. Please find for the string CMS_OVERLAY.
DB looks fine to me. So only DD can be the issue.

I don't have the time (nor interest) to debug your issue - but I suggest you check the logs very carefully to ensure that $session is getting set uniquely on each and every run of the deployment - because if it isn't, then you are essentially down from two keys (SessionKey and OverlayId) to just one (OverlayId) and that would explain why data is getting overwritten.

Good luck figuring it out.