yes there is a content type on the target server with id 343 which is correctly mapped to the one on the source server. but it appears to suggest the id 343 is on the source server - it is possible that there was one at some point but has obviously been deleted before packaging. why does the source server remember deleted items?
You can alter MSM’s memory of items regarding the source and target. When deploying the MSM to the target system, you’re eventually presented with the Element Maps tab. Below that is an Advanced… tab. After clicking that, you can go into the Content Type, and remove the source to target mapping that MSM has “cached.” Then you’ll have to define the new source to target mapping like you normally would for new items.
Check the source server’s database in the RXCONTENTTYPECOMMUNITY table, and see if there is a row with the COMMUNITYID matching the community you are trying to install with MSM, and the CONTENTTYPEID of 343. If you find such a row, and you are certain there is no row in the CONTENTTYPES table with the same CONTENTTYPEID, then delete this row from the RXCONTENTTYPECOMMUNITY table.
Then recreate the archive on the source server (hopefully you saved a descriptor) and trying installing it.
the thing that is confusing me here is that slot 376 has obviously been deleted in the past.
variant 784 is a new variant that have created with my current development. the 2 things have never existed at the same time so how has rhythmyx created a dependency between them?
In the repository database of the Rhythmyx server from which you are creating the MSM archive (the “source” server’s database), search the RXVARIANTSLOTTYPE table for a row with VARIANTID=784 and SLOTID=376. If you find such a row, delete it and then re-create the archive.