Hi Jean
I asked for support from the developers as well as server administrators. All ‘caused by’ errors refer to the table “Migration V2_38_36__Drop_users_table.sql” any clue?
we upgrade the DHIS2 system from 2.32.7 . at first step - to version 2.33.9 I’ve got the error below. I’ve verifies there is o SQL views, or any customization done. Any ideas what can I do?
SQL State : 23505
Error Code : 0
Message : ERROR: could not create unique index “seqnumcount_pkey”
Detail: Key (owneruid, key)=(ZkgX9d3pBhN, ZS_LUAL-20201040-SEQUENTIAL(#####)) is duplicated.
Location : org/hisp/dhis/db/migration/2.33/V2_33_27__Add_sequentialcounter_procedure.sql (/file:/home/dhis/tomcat-dhis/webapps/ROOT/WEB-INF/lib/dhis-support-db-migration-2.33.9.jar!/org/hisp/dhis/db/migration/2.33/V2_33_27__Add_sequentialcounter_procedure.sql)
Line : 3
Statement : – create composite primary key
alter table sequentialnumbercounter add constraint seqnumcount_pkey primary key (owneruid, key)
I’m uncertain how you have ended up in this state. I’ll have a look at our upgrade scripts to make sure they are correct. However, let me offer you a solution to the issue at hand:
Look up your duplicate records:
SELECT * FROM sequentialnumbercounter WHERE owneruid=‘ZkgX9d3pBhN’ AND key=‘ZS_LUAL-20201040-SEQUENTIAL(#####)’
This should return more than 1 row - Which is the problem. Have a look at the “counter” column. You only want to keep the record with the highest “counter” value. If multiple rows have the same value, pick any one of them to keep.
Delete the rows that you have a lower “count” value (Or that have the same count value as the one you chose)
DELETE FROM sequentialnumbercounter WHERE id=_id_to_delete
Re-run the upgrade.
If the problem persists, that means other records have been duplicated as well. In that case, repeat the steps above, exchanging the owneruid and key criteria to match the new duplicate record.
As to the reason you might have ended up in this situation, it might be related to the fix we made in this upgrade script. Previously there was a small chance to end up with so-called race-conditions when generating new unique values for attributes. If for some reason two people request new values at the same time, and neither finds the record already exists, it would insert a duplicate.