Looking at mapping associations, and I have a couple of questions where I’m not sure I’ve seen the answers here:
1. It appears that it’s okay for an association type to not have a male or female counterpart in TR_XREF, correct? That being true, when that type of association is created, there will be one tx_xref record with a valid association type and one with a null type. The one with the null type may be either a hard or soft association. This will result in an entry in TRU_ASSOCIATION_MAPPING with a blank in the Sort and Cur Xref Type columns, and this is all okay? (from a post by Dale Aucoin, it sounded like these could/would be a sign of malformed associations, in which case part of my premise must be wrong)
2. We have a number of records where the associated type is not the same as the male or female counterpart for the first type. For example, the counterparts for Employer are Employee, but we have quite a few records where the one side is Employer and the other side is Assistant, Director, Reporter, Editor, etc. Another example is Client vs Attorney, Agent, Contractor, etc.
I suspect what we’ll need to do is create types that apply to each of these counterparts individually, but want to make sure that’s the right course before I get on with it
Chris,
I have quite a few issues with tx_xref from a bad conversion so let me see if I can help.
When an association is created in Tessitura, regardless of whether it is a soft or hard association, two rows are created in TX_XREF. Both will have a TYPE - type should not be null in this table.
If it is a soft assocation, the associate_no will be null on the main row in tx_xref and the other row - the inverse row - customer_no will be null.
Prior to V11, it was ok to only have one row per association in tx_xref but this will cause problems when mapping in TRU_ASSOCIATION_MAPPING.
In answer to your second question, it is ok to have an association that maps to multiple inverse associations, you just have to create those types in TR_ASSOCIATION_TYPE.
Dale