We are using SP 4.5 sp 11. I have added 3 new classifications for service calls. An existing classification and two of the new classifications are children of a new parent. No matter how I setup my ACES package I keep getting the following error:
Violation of PRIMARY KEY constraint 'COD_PK'. Cannot insert duplicate key in object 'ITSM_CODES'., SQL state: 23000 for query: INSERT INTO itsm_codes ( cod_oid ,cod_cod_oid ,cod_disabled ,cod_lockseq ,cod_subtype ) VALUES ( ? ,? ,0 ,? ,?)
The child classification go in find though I do get errors indicating they couldn't be related to the parent (which makes sense since it doesn't get created). I have tried renaming the classification and doing an aces package with just the one classification and I get the same error. I tried this on separate environments and get the same results. I am also selecting the option to overwrite existing items by the way.
Obviously we can manually add the classification (I tried and it worked) but the people doing the actual push into production aren't well versed in Service Desk administration.
Any ideas how I should approach this?
You can observe a lot just by watching. - YOGI BERRA
Re: Aces error for new Service Call classifications
It looks as if ACES is trying to assign an OID to a new item, but that OID already exists. Or perhaps the parent of a code has a different OID in your two instances. Is it possible that the database was ever modified directly, rather than using the OVSD client, DataExchange, the Web API, or ACES?, You should be able to verify this by identifying the objectionable record in the XML file, and seeing if the OID value already exists.
Whatever the cause, here are some tips. We find that ACES works about 98% of the time, so we periodically copy the production database to the QA and the test databases. This ensures that all OIDs are synchronized, and that ACES should work in the future.
When we have difficulties with ACES, we try to migrate items one at a time. With the few number of codes you have created, this should not be too cumbersome.
Also, I believe that for hierarchical code values, ACES is supposed to be able to move a whole branch of the hierarchy just be naming the parent of that branch, and without naming explicitly all the child codes. I do not know if this is a feature introduced by a certain SP or not.
Another approach is to bite the bullet and delete the codes in the target database, then redo ACES. Depending on the rest of your configuration, and your data, this might be extremely tedious to do, and is only a last resort.