Primary Key data type change in nms:recipient without breaking references | Community
Skip to main content
M
MaciejAn1
New Member
August 25, 2025
Solved

Primary Key data type change in nms:recipient without breaking references

  • August 25, 2025
  • 1 reply
  • 2236 views

In ACC in the nms:recipient table there is auto-increment primary key (long type). However, our internal architecture requires a string(36) primary key to align with CDP and downstream integrations. Data has already been loaded before, and initial campaigns have populated related logs and references (all nms). Changing the nms primary key type in place (from long to string) would probably break references across other tables. The challenge is to resolve this issue without any data loss.

 

Is it possible to update it in nms:recipient and all reference tables without destroying current database?

 

If not - I was thinking about creating custom recipient data schema (with string PK) and defining new custom dedicated logs schemas and new target mapping and keeping existing data schemas for historical use. After that route new deliveries to new dimension. I've never used a custom solution, what things do I need to remember?

Best answer by Rch_


Hi @maciejan1 ,

 

Can you change the primary key in `nms:recipient`?

Unfortunately, no — it’s not safe or supported.

The `@id` field is used everywhere in Adobe Campaign (logs, tracking, deliveries, etc.). Changing its type (e.g. from `long` to `string`) would break those internal links and could corrupt your database. ACC doesn’t automatically update related references, so this kind of change isn’t feasible.

---

Can you recreate relationships (like in `trackingLog`) using a new PK?

Not really.

The built-in system tables are tightly linked to `@id`. You can’t just point them to a new key — those foreign keys aren’t meant to be changed, and doing so could break core functionality.

---

Does the 3-step plan make sense?

The logic makes sense in a traditional database**, but it doesn’t work in ACC.

You can’t safely change the primary key or remap those relationships — too many built-in dependencies rely on the original structure.

---

So what’s the safe approach?

* Keep `@id` as-is
* Add a new `uuid` (string) field to `nms:recipient`
* Use that `uuid` for external integrations (CDP, etc.)
* (Optional) Set up a custom recipient schema with `uuid` as the primary key for future use

This lets you meet external requirements without risking platform stability.

 

Thanks,

 

1 reply

ParthaSarathy
Community Advisor
ParthaSarathyCommunity Advisor
Community Advisor
August 25, 2025

Hi @maciejan1 ,

When you change the data type of an attribute, the existing field will get dropped (@id integer will get deleted) and new attribute with new data type (@id string) will get created. So the data of ID will get deleted and this will be having impact. So either you can take a backup of all the data and reload it after the data type modification. Or as you mentioned, you can create a custom table to store this history data and then modify the data type. I would suggest try the same in lower environment or in a test schema - before modifying in Production.

~  ParthaSarathy S~  Click here to join ADOBE CAMPAIGN USER GROUP for Quarterly In-person | Hybrid | Virtual Meetups
    M
    MaciejAn1Author
    New Member
    August 25, 2025

    Is it even possible to update primary key in nms:recipient table? What about existing references? Will ACC allow me to perform such update?

    Is it possible to recreate relationships e.g. in trackingLog using new PK?

     

    e.g.

    1) I'm creating mapping old PK:new PK

    2) Based on mapping, I'm adding new column with new PK to tables related to nms:recipient

    3) after it's done I'm starting to change recipientId data type in all tables keeping old PK in other column just in case sth goes wrong

     

    Does it make sense?

    Rch_
    Rch_Accepted solution
    Level 3
    August 25, 2025


    Hi @maciejan1 ,

     

    Can you change the primary key in `nms:recipient`?

    Unfortunately, no — it’s not safe or supported.

    The `@id` field is used everywhere in Adobe Campaign (logs, tracking, deliveries, etc.). Changing its type (e.g. from `long` to `string`) would break those internal links and could corrupt your database. ACC doesn’t automatically update related references, so this kind of change isn’t feasible.

    ---

    Can you recreate relationships (like in `trackingLog`) using a new PK?

    Not really.

    The built-in system tables are tightly linked to `@id`. You can’t just point them to a new key — those foreign keys aren’t meant to be changed, and doing so could break core functionality.

    ---

    Does the 3-step plan make sense?

    The logic makes sense in a traditional database**, but it doesn’t work in ACC.

    You can’t safely change the primary key or remap those relationships — too many built-in dependencies rely on the original structure.

    ---

    So what’s the safe approach?

    * Keep `@id` as-is
    * Add a new `uuid` (string) field to `nms:recipient`
    * Use that `uuid` for external integrations (CDP, etc.)
    * (Optional) Set up a custom recipient schema with `uuid` as the primary key for future use

    This lets you meet external requirements without risking platform stability.

     

    Thanks,

     

    Terms & ConditionsAccessibility statement

    Loading footer...