TRU_ASSOCIATION_MAPPING

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

Parents
  • We have no associations with only one row, but lots of them have a null type because there was no counterpart type in the reference table TR_XREF for it to put in the associated record

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Dale Aucoin
    Sent: Thursday, March 29, 2012 10:54 AM
    To: Chris Roe
    Subject: RE: [Tessitura Next Generation Forum] TRU_ASSOCIATION_MAPPING

     

    Chris,

    If you're creating the associations in Tessitura in a constituent's record, 2 rows are always generated in tx_xref.

    The only way you could create an association with just one row in tx_xref is if you imported data from a spreadsheet or another database.

    Dale

    From: Chris Roe <bounce-chrisroe2124@tessituranetwork.com>
    Sent: 3/29/2012 12:48:05 PM

    Thanks Dale!  - so it sounds like it’s NOT okay for a TR_XREF entry to have no counterparts, even though the system allows you to enter them that way?

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Dale Aucoin
    Sent: Thursday, March 29, 2012 9:59 AM
    To: Chris Roe
    Subject: Re: [Tessitura Next Generation Forum] TRU_ASSOCIATION_MAPPING

     

    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

    From: Chris Roe <bounce-chrisroe2124@tessituranetwork.com>
    Sent: 3/29/2012 11:05:19 AM

    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




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!




    You were sent this message automatically by www.tessituranetwork.com because you subscribed to the Tessitura Next Generation forum email notifications. You may reply to this message or visit the site to reply to the post above. If replying via email, please consider deleting the previous message text before sending to help with readability on the site. Thank you!

  • I see what you're saying.

    I'm no expert on V11 mapping but I would think you would need to fix those before you map to V11.


    Dale 

  • Hello,

    When we are talking about associations that only have one row in tx_xref are we talking about those rows where the xref_no_inv is NULL?

    If so, I have a lot of those.

    Jared

  • Each association needs two rows in tx_xref.  Those two rows need to be associated to each other via xref_no_inv.

    If you have rows with null xref_no_inv, I would think you need to fix this before you can map to V11.

    Dale

  • Unknown said:

    If you have rows with null xref_no_inv, I would think you need to fix this before you can map to V11.

    We can confirm Dale's experience here - NULL xref_no_inv's will be bad, as will duplicate xref_no_inv's. Though associations like that may have lived happily up to and including v10, either one will very likely cause MP_COMMIT to crash during the migration.

  • Exactly.  The migration process (staging and commit) assumes that all data in TX_XREF is well-formed. That is that EVERY row (hard and soft associations) each have another row that is the 'inverse' side of the association and is pointed at with xref_no_inv. 

    Another situation that can cause problems is a row that is pointing at itself. (Cue Billy Idol singing "Dancing with myself"...)

     

Reply
  • Exactly.  The migration process (staging and commit) assumes that all data in TX_XREF is well-formed. That is that EVERY row (hard and soft associations) each have another row that is the 'inverse' side of the association and is pointed at with xref_no_inv. 

    Another situation that can cause problems is a row that is pointing at itself. (Cue Billy Idol singing "Dancing with myself"...)

     

Children
No Data