• Replies 15 replies
  • Subscribers 343 subscribers
  • Views 44 views
  • Users 0 members are here
Related

Ticket History from v11 to v12

Ray Bernard
$organization

Hi,

At the Science Museum, we have legacy ticket data from our previous software, in v11 (and  previous versions)  in Ticket History. In testing the migration to v12 this valuable information is not longer readily available. While we like the greater detail in the v12 History, we don't want to lose ready access to legacy data. Have any other organizations encountered this? How are you handling it? Are there any alternatives for scripted "back filling"of  this data into v12constituent records post migration?

Thanks.

Ray

Parents
  • $organization

    We’re in the same boat as Ken and Chris. We do not have as many custom elements as Ken has, but we do have some that are important. At this point, that unfortunately means we have to build a custom version of the screens just to handle 2-3 additional elements.

     

    We too have data from a legacy system that needs to be displayed in the history screens.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Chris Jensen
    Sent: Thursday, February 6, 2014 10:21 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Ticket History from v11 to v12

     

    Having dug into this a bit more, I agree with Ken re: "mov[ing] to the new standard ticket history, particularly because I assume that Tess will continue to develop new functionality based around this mode", and also agree with him re: adding some "standard custom" columns to the new history tables, much as they are in T_ORDER and T_CONTRIBUTION, would be a good idea, as he described below:

    Ken McSwain:

    • 10 varchar(50) fields called text_0 through text_9; 
    • 10 int fields called int_0 through int_9, and 
    • 10 datetime fields called dt_0 through dt_9, 
    • plus a hook in the update proc to call a local proc to fill them. 
    • Maybe some other data types (Money?) as well. 

    In our case there is unconverted, historical data from a legacy ticketing system that will never have Tessitura perf_no's or price_type ids, for example, but could be fit into the standard history table if it had the columns described above.

    From: Ken McSwain <bounce-kenmcswain5454@tessituranetwork.com>
    Sent: 1/16/2014 5:48:03 AM

    Hi folks

    Having looked at some more detail on this - I would like to move to the new standard ticket history, particularly because I assume that Tess will continue to develop new functionality based around this model; but I can't see how we could do it, and maintain our ability to import external ticket history. 

    The ideal solution, obviously, would be to import orders instead of ticket history, and that's certainly a target, but may be a lot of work away for some non-tess venues, and won't work for existing non-tess data in any case.

    One way to enable us to keep using our existing local functionality, but still use standard tables, would be for Tess to extend the table with a clutch of custom fields that sites could fill with whatever data they needed - say

    • 10 varchar(50) fields called text_0 through text_9; 
    • 10 int fields called int_0 through int_9, and 
    • 10 datetime fields called dt_0 through dt_9, 
    • plus a hook in the update proc to call a local proc to fill them. 
    • Maybe some other data types (Money?) as well. 

    Presumably they wouldn't be visible in the history screens, but we don't really care about that, I think - they're mostly used in List elements or reporting, or just for admin purposes.

    Does that sound possible? Is that a v14 enhancement request? What does Anna think?

    Just as a f'rinstance, these are our current fields that we wouldn't want to do without:

    • [hist_source] [char](1) , whether the data came from Tess, one of the legacy systems, or an import ,
    • [Source_no] [int] , Tess source number (sometimes we get that from external venues)
    • [Hist_Source_System] [varchar](50) , The alien system that we imported from (eg "Enta - QPAC")
    • [Hist_Source_Cust_id] [varchar](50) , the customer's id in that system
    • [Hist_Source_Description] [varchar](50) , a description of the particular import ( eg "ACO 2014 Tour 2 QPAC")
    • [Import_Session_id] [int] , link to the specific import session
    • [Hist_Source_Row_id] [int] , and the row in the import data
    • [soh_access] [int] , the funny one for SOH access purposes

     

    Ken

     




    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!

Reply
  • $organization

    We’re in the same boat as Ken and Chris. We do not have as many custom elements as Ken has, but we do have some that are important. At this point, that unfortunately means we have to build a custom version of the screens just to handle 2-3 additional elements.

     

    We too have data from a legacy system that needs to be displayed in the history screens.

     

    Thanks,

    David

     

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Chris Jensen
    Sent: Thursday, February 6, 2014 10:21 AM
    To: David Frederick
    Subject: Re: [Tessitura Technical Forum] Ticket History from v11 to v12

     

    Having dug into this a bit more, I agree with Ken re: "mov[ing] to the new standard ticket history, particularly because I assume that Tess will continue to develop new functionality based around this mode", and also agree with him re: adding some "standard custom" columns to the new history tables, much as they are in T_ORDER and T_CONTRIBUTION, would be a good idea, as he described below:

    Ken McSwain:

    • 10 varchar(50) fields called text_0 through text_9; 
    • 10 int fields called int_0 through int_9, and 
    • 10 datetime fields called dt_0 through dt_9, 
    • plus a hook in the update proc to call a local proc to fill them. 
    • Maybe some other data types (Money?) as well. 

    In our case there is unconverted, historical data from a legacy ticketing system that will never have Tessitura perf_no's or price_type ids, for example, but could be fit into the standard history table if it had the columns described above.

    From: Ken McSwain <bounce-kenmcswain5454@tessituranetwork.com>
    Sent: 1/16/2014 5:48:03 AM

    Hi folks

    Having looked at some more detail on this - I would like to move to the new standard ticket history, particularly because I assume that Tess will continue to develop new functionality based around this model; but I can't see how we could do it, and maintain our ability to import external ticket history. 

    The ideal solution, obviously, would be to import orders instead of ticket history, and that's certainly a target, but may be a lot of work away for some non-tess venues, and won't work for existing non-tess data in any case.

    One way to enable us to keep using our existing local functionality, but still use standard tables, would be for Tess to extend the table with a clutch of custom fields that sites could fill with whatever data they needed - say

    • 10 varchar(50) fields called text_0 through text_9; 
    • 10 int fields called int_0 through int_9, and 
    • 10 datetime fields called dt_0 through dt_9, 
    • plus a hook in the update proc to call a local proc to fill them. 
    • Maybe some other data types (Money?) as well. 

    Presumably they wouldn't be visible in the history screens, but we don't really care about that, I think - they're mostly used in List elements or reporting, or just for admin purposes.

    Does that sound possible? Is that a v14 enhancement request? What does Anna think?

    Just as a f'rinstance, these are our current fields that we wouldn't want to do without:

    • [hist_source] [char](1) , whether the data came from Tess, one of the legacy systems, or an import ,
    • [Source_no] [int] , Tess source number (sometimes we get that from external venues)
    • [Hist_Source_System] [varchar](50) , The alien system that we imported from (eg "Enta - QPAC")
    • [Hist_Source_Cust_id] [varchar](50) , the customer's id in that system
    • [Hist_Source_Description] [varchar](50) , a description of the particular import ( eg "ACO 2014 Tour 2 QPAC")
    • [Import_Session_id] [int] , link to the specific import session
    • [Hist_Source_Row_id] [int] , and the row in the import data
    • [soh_access] [int] , the funny one for SOH access purposes

     

    Ken

     




    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!

Children
No Data