
There is an issue with recID duplicates.
We have an old AX 3.0 still working.
However few days ago we started to have ramdomly issues with record duplicates. After short investigation we found that system is trying to write recId which already exists. It seems that we finished possible values to get recId. This is because AX 3.0 shares recId for all tables in one company.
We found ad hoc workaround.
Constructed job which is finding a pool of not existing recIds, and we are puting (manually) the first number of that recId to table SystemSequences.
We are trying to implement temporary solution, to update this information in SystemSequences.nextval, after each insert to any AX table.
We have a list of not used recId in one table, and after any insert we would like to change this value in SystemSequences.nextVal to number from our list.
What is also important, as I know AOS is caching 250 numbers of next recId.
So, how can we disable this cache on AOS? We don't want to restart AOS few times during working day.
I know that this solution may slow down system, but:
1. We are during migration to AX 2012, so AX 3.0 will work to the and of this year
2. AX 3.0 is working extremaly fast on our servers, because they are now prepared for AX 2012, so any slow down even 10 times, will still be workable.
3. We don't have as much inserts in our database.
*This post is locked for comments
I have the same question (0)Did I understand your issue correctly, in that you've exhausted the maximum range of RecId's from the maximum negative value to the maximum positive value? And you basically only have small gaps in the sequence and you're forced to use up those gaps to get by for now?
In AX 3.0, the RecId system sequence was per company. You should be able to use the same RecId in different companies, for a given table number. It wasn't until AX 4.0 that the RecId became global for a given table, i.e. unique across all companies. The migration to AX 4.0 renumbered the RecId's of all records in a table. I don't see why it wouldn't about to do the same thing for you going to AX 2012.
Of course there are challenges to renumbering RecId's, because they might be referenced by other tables.
You are stuck with 32-bit RecId's on AX 3.0, but you might still be able to renumber to RecId's in your troubled table to get you by until the AX 2012 upgrade. What table is giving you the issue? Is it one that is referenced by other tables? Does it have references, for example, in DocuRef (Document handling)? If so, then the references need fixed too or they'll break. The upgrade to AX 4.0 does that.