How to implement new sequence of IDs in subscription history table (subHisto schema) | Community
Skip to main content
alik98709228
Level 2
July 11, 2021
Solved

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

  • July 11, 2021
  • 3 replies
  • 1841 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by xavierv6303633

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.

3 replies

Krishnanunni
Level 4
July 14, 2021

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?

xavierv6303633
xavierv6303633Accepted solution
Level 2
July 19, 2021

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.

Sukrity_Wadhwa
Community Manager
Community Manager
July 28, 2021

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