TR_NAME_STATUS

Former Member
Former Member $organization

At Bass Hall - Fort Worth, we're still learning the front and back sides of Tessitura.

Recent posts regarding SSRS have been very helpful (thank you), and I'm beginning to develop some preliminary reports.
It may help to create one or more database views containing patron data, and I'm puzzled about one customer field.

I'm familiar with the active flag (link to TR_INACTIVE_REASON) in T_CUSTOMER, and how it (essentially) removes a customer record from the database.
We're considering add'tl values for TR_NAME_STATUS, but I'm puzzled how the database uses this table.


A "Status" field exists on the patron record, and the value for this field is pulled from TR_NAME_STATUS - kinda.

For a specific patron, the name_status column in T_CUSTOMER displays NULL.
In the application, for this specific patron, the Status column displays Active (id 1 for TR_NAME_STATUS = "Active").
I changed the value in TR_NAME_STATUS from "Active" to "ACTIVEXXX".
In the application the Status field for the specific patron displayed "ACTIVEXXX".
And yet, in T_CUSTOMER, the value in name_status still displays NULL.

It appears "something" is telling the application to display "Active" in the status field if name_status IS NULL OR name_status = 1.

Does the application determine the value, or is there a database view that determines the value?
Most of our customer records have NULL in T_CUSTOMER.name_status.  Should this value be updated?

What am I missing?

Thanks
Wendell Baskin

  • Former Member
    Former Member $organization

    Hi Wendell,

    If you are looking at an individual record, "Status" on the Name line is what is tied to this value. In every organization I've dealt with, this field is ignored.  The value (as far as I know) does not trigger any other behaviors in the system.  

    Historically, some organizations used this field to indicate a deceased patron. In versions of Tess prior to version 11 it was possible to have two individuals on the same record.  You can see vestiges of this in T_CUSTOMER (fname, fname2,lname,lname2, etc). This led to a situation where one name on the record was deceased while the other was still living. They needed a way to show that the individual was deceased without inactivating the record.  With the new constituent model introduced in V11 this was no longer an issue.  

    My recommendation would be to simply ignore the Status field unless Bass Hall has developed specific business practices which utilize it.  There really isn't much you can do with it that can't be accomplished in a more elegant way with a different piece of Tessitura functionality.

    - Levi

  • Former Member
    Former Member $organization

    Thank you, Levi ..

     

    some organizations used this field to indicate a deceased patron

    We have used this field to indicated deceased patrons (it does affect the constituent header).

    This allows Development to process soft credits and can be used to eliminate the patron from mailings.

    At some point we would inactivate the patron record.

     

    How do you indicate deceased patrons?

    Wendell

     

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Levi Sauerbrei
    Sent: Tuesday, October 22, 2013 10:19
    To: Wendell Baskin
    Subject: Re: [Tessitura Technical Forum] TR_NAME_STATUS

     

    Hi Wendell,

    If you are looking at an individual record, "Status" on the Name line is what is tied to this value. In every organization I've dealt with, this field is ignored.  The value (as far as I know) does not trigger any other behaviors in the system.  

    Historically, some organizations used this field to indicate a deceased patron. In versions of Tess prior to version 11 it was possible to have two individuals on the same record.  You can see vestiges of this in T_CUSTOMER (fname, fname2,lname,lname2, etc). This led to a situation where one name on the record was deceased while the other was still living. They needed a way to show that the individual was deceased without inactivating the record.  With the new constituent model introduced in V11 this was no longer an issue.  

    My recommendation would be to simply ignore the Status field unless Bass Hall has developed specific business practices which utilize it.  There really isn't much you can do with it that can't be accomplished in a more elegant way with a different piece of Tessitura functionality.

    - Levi

    From: Wendell Baskin <bounce-wendellbaskin7249@tessituranetwork.com>
    Sent: 10/22/2013 10:00:22 AM

    At Bass Hall - Fort Worth, we're still learning the front and back sides of Tessitura.

    Recent posts regarding SSRS have been very helpful (thank you), and I'm beginning to develop some preliminary reports.
    It may help to create one or more database views containing patron data, and I'm puzzled about one customer field.

    I'm familiar with the active flag (link to TR_INACTIVE_REASON) in T_CUSTOMER, and how it (essentially) removes a customer record from the database.
    We're considering add'tl values for TR_NAME_STATUS, but I'm puzzled how the database uses this table.


    A "Status" field exists on the patron record, and the value for this field is pulled from TR_NAME_STATUS - kinda.

    For a specific patron, the name_status column in T_CUSTOMER displays NULL.
    In the application, for this specific patron, the Status column displays Active (id 1 for TR_NAME_STATUS = "Active").
    I changed the value in TR_NAME_STATUS from "Active" to "ACTIVEXXX".
    In the application the Status field for the specific patron displayed "ACTIVEXXX".
    And yet, in T_CUSTOMER, the value in name_status still displays NULL.

    It appears "something" is telling the application to display "Active" in the status field if name_status IS NULL OR name_status = 1.

    Does the application determine the value, or is there a database view that determines the value?
    Most of our customer records have NULL in T_CUSTOMER.name_status.  Should this value be updated?

    What am I missing?

    Thanks
    Wendell Baskin




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • Former Member
    Former Member $organization in reply to Former Member

    In version 10 and earlier, some organizations would change the name status of the deceased patron to "Deceased". Once the second patron on the record passed away, the record would be inactivated.

    The only reason you might want to do this in the current version is if there is some reason that you want a deceased patron to remain active in the database.  Inactivating the record excludes them from lists and extractions by default which prevents emails, postal mail, phone lists, etc from containing deceased patrons. So changing name status but NOT inactivating the account can lead to some messy situations (for instance, a bereaved family receiving a subscription renewal notice for a family member who has recently passed away). 

    If there is a planned gift associated with the patron (the had bequeathed something from their estate to the organization) I would recommend changing the account type to Estate and altering the name on the account to something like "The Joseph Jones Estate" to prevent any confusion.

     I had forgotten about the header change because all of our custom headers ignore it, but I believe the headers that come with Tessitura do show it.

    Hope that helps! Give me a call if you'd like to discuss it in more detail.

    - Levi

  • Unknown said:
    How do you indicate deceased patrons?

    We've always used a DEC constituency, and have never used NAME_STATUS. After a little time the DEC's get inactivated.

  • If the Ignore or Sal box is checked on a status value in TR_NAME_STATUS, names with that status will be ignored when household names and salutations are generated.  So even in v11, it still has some value for individuals who have houeholds.

     

    Kevin Sheehan

    Senior Technical Writer & Consultant

    Tessitura Network

    +1 888 643 5778 x 329

    ksheehan@tessituranetwork.com