Expand my Community achievements bar.

Announcing the launch of new sub-community for Campaign Web UI to cater specifically to the needs of Campaign Web UI users!
SOLVED

How to implement new sequence of IDs in subscription history table (subHisto schema)

Avatar

Level 3

Hello,

 

Our workflow is erroring out due to using IDs in subHisto table that already been used.

Is there a way to resolve that issue or could we used a custom script to force ACC to find an unused IDs?

 

Let me know.

 

Thanks!

 

AK

1 Accepted Solution

Avatar

Correct answer by
Level 3

Hi @alik98709228,

 

This can happen when your sequence (xtkNewId) has gone to its maximum value and started over at 0. Whenever that sequence catches up to the lowest ID present in your table, you will receive this error. This will be the case for ALL native tables though (with the excpetion of delivery logs), so it's a big issue.

 

If you're working in v6, that sequence is a 32bit integer, so it's capped at +- 2.100.000.000. I solved this issue myself by adapting the sequence and the primary key of my table to a 64bit int. A quick fix can also be to reset the sequence to 0 and let it go into negative numbers, although this is not recommended.

View solution in original post

3 Replies

Avatar

Level 4

Hi @alik98709228 ,
Are you trying to insert records to subHisto table? According to my understanding, this schema is automatically updated during subscription or unsubscription actions. Also, this schema has the autopk=true, which means, it increment the id value each time during an insert. If you are trying to insert record, can you try without inserting the id field?

Avatar

Correct answer by
Level 3

Hi @alik98709228,

 

This can happen when your sequence (xtkNewId) has gone to its maximum value and started over at 0. Whenever that sequence catches up to the lowest ID present in your table, you will receive this error. This will be the case for ALL native tables though (with the excpetion of delivery logs), so it's a big issue.

 

If you're working in v6, that sequence is a 32bit integer, so it's capped at +- 2.100.000.000. I solved this issue myself by adapting the sequence and the primary key of my table to a 64bit int. A quick fix can also be to reset the sequence to 0 and let it go into negative numbers, although this is not recommended.

Avatar

Administrator

Hi @alik98709228,

Were any of the given solutions helpful to resolve your query or do you still need more help here? Do let us know.

Thanks!



Sukrity Wadhwa