Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

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

alik98709228
Level 3
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
xavierv6303633
Correct answer by
Level 3
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
Krishnanunni
Level 4
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?

xavierv6303633
Correct answer by
Level 3
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

Sukrity_Wadhwa
Employee
Employee

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!