• Replies 2 replies
  • Subscribers 358 subscribers
  • Views 24 views
  • Users 0 members are here
Related

Teacher Tempestuousness

Matt Gonzales
$organization

Originally, our teacher records were inadvertently set up as OI records - with the teacher's name on both N1 and N2.  And now, in light of the migration, we're trying to figure out the right course with the following background:

  • The records are set up as n1n2_format OI in the TR_CUST_TYPE table as well as in the T_CUSTOMER record.
  • The Teacher name is in both the N1 and the N2 fields, and we only want to generate one new customer record.
  • It was decided to manually change those records on the back end first, by copying the fname2, mname2, lname2, etc to the corresponding name1 fields and clearing out the n2 field information, as well as changing the n1n2_format field in T_CUSTOMER to II.
  • In the TRU_CUSTOMER_MAPPING table, the fields are set as follows:
    • N1n2 Format: OI
    • Cur Cust Type: Teacher
    • New Group Cust Type: (blank)
    • New A1 Cust Type: Teacher
    • N1 Affil Type: Employee
    • New A2 Cust Type: Individual
    • N2 Affil Type: Primary Contact

So, should I also change the n1n2_format field in TR_CUST_TYPE and what effect does making that change have on the existing records (is it safe)?

As it turned out, when I went to fill out the TRU_CUSTOMER_MAPPING table row for Teacher (because the pre-migration script complained that it was not completely mapped), reasoned that the manual change to the T_CUSTOMER teacher entries should not be necessary with the appropriate changes made to the TRU_CUSTOMER_MAPPING teacher entry.  Admittedly, there was a bit of wishful/magical thinking involved here fueled by my experimental nature.  And I was wrong.

In the aftermath, it turns out that teachers were created as a School constituent type, with the original N2 information as the A1 affiliate record.

How should I have done this in order to have the original records migrate to a new individual record with constituent type of Teacher and no affiliates (associations to current school employer, yes)?

Thank you for your suggestions.

Parents
  • $organization

    Nick,

     

    I would be very interested in seeing that script, thank you.  I assumed it worked for you, right?  And did  you have to change the n1n2 format in both the TR_CUST_TYPE table and the individual records?  One of my main concern was whether changing the format at the TR_CUST_TYPE level would somehow cause any trouble for the individual records, like wiping out any pre-existing data.

     

    Matt Gonzales

    Database Administrator

    Houston Grand Opera

    510 Preston St | Suite 500, 5th Floor

    (v) 713-980-8702 | (f) 713-225-2574

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Nick Insell
    Sent: Thursday, May 24, 2012 4:00 AM
    To: Matt Gonzales
    Subject: Re: [Tessitura Next Generation Forum] Teacher Tempestuousness

     

    Hi Matt

    We had a similar problem with the way our schools where setup.  In the end we decided to convert all of the records to Corporate Contacts (IO names) before we carried out the migration.  I wrote a script that went through an converted any records that had a last name 2 and were setup as organisations (OI) to Corportate Contacts.

    I can send this over if you need it?

    Thanks

    Nick

    From: Matt Gonzales <bounce-mattgonzales9808@tessituranetwork.com>
    Sent: 5/23/2012 5:52:30 PM

    Originally, our teacher records were inadvertently set up as OI records - with the teacher's name on both N1 and N2.  And now, in light of the migration, we're trying to figure out the right course with the following background:

    • The records are set up as n1n2_format OI in the TR_CUST_TYPE table as well as in the T_CUSTOMER record.
    • The Teacher name is in both the N1 and the N2 fields, and we only want to generate one new customer record.
    • It was decided to manually change those records on the back end first, by copying the fname2, mname2, lname2, etc to the corresponding name1 fields and clearing out the n2 field information, as well as changing the n1n2_format field in T_CUSTOMER to II.
    • In the TRU_CUSTOMER_MAPPING table, the fields are set as follows:
      • N1n2 Format: OI
      • Cur Cust Type: Teacher
      • New Group Cust Type: (blank)
      • New A1 Cust Type: Teacher
      • N1 Affil Type: Employee
      • New A2 Cust Type: Individual
      • N2 Affil Type: Primary Contact

    So, should I also change the n1n2_format field in TR_CUST_TYPE and what effect does making that change have on the existing records (is it safe)?

    As it turned out, when I went to fill out the TRU_CUSTOMER_MAPPING table row for Teacher (because the pre-migration script complained that it was not completely mapped), reasoned that the manual change to the T_CUSTOMER teacher entries should not be necessary with the appropriate changes made to the TRU_CUSTOMER_MAPPING teacher entry.  Admittedly, there was a bit of wishful/magical thinking involved here fueled by my experimental nature.  And I was wrong.

    In the aftermath, it turns out that teachers were created as a School constituent type, with the original N2 information as the A1 affiliate record.

    How should I have done this in order to have the original records migrate to a new individual record with constituent type of Teacher and no affiliates (associations to current school employer, yes)?

    Thank you for your suggestions.




    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!

Reply
  • $organization

    Nick,

     

    I would be very interested in seeing that script, thank you.  I assumed it worked for you, right?  And did  you have to change the n1n2 format in both the TR_CUST_TYPE table and the individual records?  One of my main concern was whether changing the format at the TR_CUST_TYPE level would somehow cause any trouble for the individual records, like wiping out any pre-existing data.

     

    Matt Gonzales

    Database Administrator

    Houston Grand Opera

    510 Preston St | Suite 500, 5th Floor

    (v) 713-980-8702 | (f) 713-225-2574

     

    From: Tessitura Next Generation Forum [mailto:forums-nextgeneration@tessituranetwork.com] On Behalf Of Nick Insell
    Sent: Thursday, May 24, 2012 4:00 AM
    To: Matt Gonzales
    Subject: Re: [Tessitura Next Generation Forum] Teacher Tempestuousness

     

    Hi Matt

    We had a similar problem with the way our schools where setup.  In the end we decided to convert all of the records to Corporate Contacts (IO names) before we carried out the migration.  I wrote a script that went through an converted any records that had a last name 2 and were setup as organisations (OI) to Corportate Contacts.

    I can send this over if you need it?

    Thanks

    Nick

    From: Matt Gonzales <bounce-mattgonzales9808@tessituranetwork.com>
    Sent: 5/23/2012 5:52:30 PM

    Originally, our teacher records were inadvertently set up as OI records - with the teacher's name on both N1 and N2.  And now, in light of the migration, we're trying to figure out the right course with the following background:

    • The records are set up as n1n2_format OI in the TR_CUST_TYPE table as well as in the T_CUSTOMER record.
    • The Teacher name is in both the N1 and the N2 fields, and we only want to generate one new customer record.
    • It was decided to manually change those records on the back end first, by copying the fname2, mname2, lname2, etc to the corresponding name1 fields and clearing out the n2 field information, as well as changing the n1n2_format field in T_CUSTOMER to II.
    • In the TRU_CUSTOMER_MAPPING table, the fields are set as follows:
      • N1n2 Format: OI
      • Cur Cust Type: Teacher
      • New Group Cust Type: (blank)
      • New A1 Cust Type: Teacher
      • N1 Affil Type: Employee
      • New A2 Cust Type: Individual
      • N2 Affil Type: Primary Contact

    So, should I also change the n1n2_format field in TR_CUST_TYPE and what effect does making that change have on the existing records (is it safe)?

    As it turned out, when I went to fill out the TRU_CUSTOMER_MAPPING table row for Teacher (because the pre-migration script complained that it was not completely mapped), reasoned that the manual change to the T_CUSTOMER teacher entries should not be necessary with the appropriate changes made to the TRU_CUSTOMER_MAPPING teacher entry.  Admittedly, there was a bit of wishful/magical thinking involved here fueled by my experimental nature.  And I was wrong.

    In the aftermath, it turns out that teachers were created as a School constituent type, with the original N2 information as the A1 affiliate record.

    How should I have done this in order to have the original records migrate to a new individual record with constituent type of Teacher and no affiliates (associations to current school employer, yes)?

    Thank you for your suggestions.




    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!

Children
No Data