I am using the PackageImportExport utility SP14 (build 7022). Can you anyone advise the 2 field on the Export screen:
Level: it defaults to 1
Export Referenced Items
I tried to export the Form and ItemType for ECR. and during import, I got the error below (tried with or without Export Referenced Items option ticked):
Grid Event Already exists. Violation of Primary Key constraint.
And there is no additional info provided. I haven't had much success with the import, only worked very few items. I don't want to back up the whole database and restore it to another environment, which is not ideal when promoting changes to Prod!
Any ideas?
Hi fdxu168,
When you say you want to "replace" the ItemType, are you saying you want to remove an existing ItemType and create a brand new ItemType to replace it (with a new id)?
For example, say you decide to build your own Part ItemType instead of using the out-of-the-box Part ItemType. So you delete the Part ItemType in your source database, create a new Part ItemType, add it to a package, export it, and try to import it to a clean Aras database. This won't work because the Part ItemType you're trying to import has a different id/keyed_name pair than the Part ItemType already in the target database.
If you need to override a default ItemType/List/Form/etc. you should do so by modifying the existing item or creating a separate item in parallel rather than replacing it with your own brand new item. For the scenario I described above, it would be better to modify the OOTB Part ItemType to fit your needs or create a new ItemType like "my_Part". Either approach should avoid/reduce import errors and make the upgrade process smoother and the "rip and replace" approach.
If you absolutely have to delete and replace an item, you should delete the item from the target database before running your import. By default, import packages are additive - they will only add or update items, not delete them.
One last piece of import/export advice. Alwaysbackup your target database before executing an import. That gives you a copy to fall back on if the import breaks something or you need to diff the configuration before/after the import.
Hope this helps.
Eli
Eli Donahue
Aras Labs Software Engineer
Hi fdxu168,
When you say you want to "replace" the ItemType, are you saying you want to remove an existing ItemType and create a brand new ItemType to replace it (with a new id)?
For example, say you decide to build your own Part ItemType instead of using the out-of-the-box Part ItemType. So you delete the Part ItemType in your source database, create a new Part ItemType, add it to a package, export it, and try to import it to a clean Aras database. This won't work because the Part ItemType you're trying to import has a different id/keyed_name pair than the Part ItemType already in the target database.
If you need to override a default ItemType/List/Form/etc. you should do so by modifying the existing item or creating a separate item in parallel rather than replacing it with your own brand new item. For the scenario I described above, it would be better to modify the OOTB Part ItemType to fit your needs or create a new ItemType like "my_Part". Either approach should avoid/reduce import errors and make the upgrade process smoother and the "rip and replace" approach.
If you absolutely have to delete and replace an item, you should delete the item from the target database before running your import. By default, import packages are additive - they will only add or update items, not delete them.
One last piece of import/export advice. Alwaysbackup your target database before executing an import. That gives you a copy to fall back on if the import breaks something or you need to diff the configuration before/after the import.
Hope this helps.
Eli
Eli Donahue
Aras Labs Software Engineer
