Ticket History from v11 to v12

Clean Clean false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Hi Ray,

We haven't gone Live with V12 yet but I have been working with it in our Test environment. We also have many years of legacy data that we didn't want to disappear. My solution may not be the most elegant one but it seems to do the trick.

Basically, prior to the upgrade process I put all of our legacy ticket and package data into new local tables (one for each). I performed the Standard Ticket/Package Upgrade provided by Tess. After this was complete I inserted the data from my local tables into the new Ticket and Package history tables.

That being said, there were a couple things I noticed and questions I haven't answered yet (so I'd love to hear what others are doing as well!):

1) As long as I've been on Tess I've been told to NOT mess with tables that aren't local. So naturally, I have hesitation with simply adding our legacy data to the new Tess table structure. On the other hand if I create new local tables I have to create new local procedures to update those tables and mess around with InfoMaker to point to the new tables. I'd also have to re-point all of the new Ticket and Package history list/output set criteria to the new tables. It sounds unpleasant. Have any Live V12 organizations dealt with this issue? Did you create new or stick with the Tess supplied stuff?

2) The new ticket and package history tables have additional columns. Some of which will not accept NULL values. So you have to add those columns to your legacy data holding tables with some sort of generic value before you can import it to the new history tables. For package history I believe the only new required column is Role. For ticket history it requires order_no (can be 0 but not null), role, theater_no, MOS and pkg_no (again, 0 is appropriate).

I think that covers what I've noticed so far. I'd love to hear from other organizations (especially if they have a much better way of doing it!) and am also happy to chat more about the method I tried if anyone has questions about it.

Hi guys

We haven't looked at it in detail yet, but our first thought is that we would keep our existing, heavily customised, ticket history, and not move to the new standard ticket history at all. I believe that's possible, although strongly un-recommended. We would add the new role-y stuff into our localised version, as per the What's new notes:

NOTE: If you do not use the new, standard histories, you will need to update your customized histories to include initiator and recipient data if you want that data to be available for lists and extractions. Some instructions and examples for updating custom histories will be included in the v12 upgrade documentation.

Apart from legacy system data, we also have a lot of imported external venue and agency sales, which we bring in on an ongoing basis, and for them we keep a chunk of specialised data, plus some other very local fields (for example a field which marks a sale record as available to SOH for marketing purposes, a legacy of a complicated contract change that didn't mesh with Tess ways of doing things.) 

So I don't think we have any option other than to modify our custom tables to work with the new v12 stuff, and continue to use them. We'll see how we go.

Ken

In general if you are planning to adopt the standard ticket history, as we reccomend, then I would plan to convert your legacy data from your old ticket history to the standard history table.  This would be similar to the process that you would use when you installed Tessitura originally.  As long as you are mapping similar columns from your old ticket history to the standard ticket history the conversion should be fairly easy.  If you would like some advice or assistance feel free to contact our consulting department to discuss the options; they are available to give you advice on how you might move your data and/or to take on the project for you.

Best,

Anna

Clean Clean false false false EN-US X-NONE X-NONE

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

 

 

I've started to think about how we can move back to the standard ticket history table as we migrate to v12, and so far my plan is to create a separate table as an extension to the standard table, to hold the columns that we want that are extra. That way we can use the standard tables and functionality that Tessitura provide, but also report out on the extra bits when we want to.

Christine

Unknown said:

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.[...]

We have plenty of legacy data, too, have used heavily customized Ticket History tables table here from day 1 on Tessitura, and in addition have plenty of custom List/Extraction elements to query them. Adding initiator/recipient data to our tables sounds easier to me than trying to cram the square peg of our data into the round hole of the new standard tables, but we'll see (we are only on v12 in Test.)

Hey Ray -

Our legacy history didn't contain too many custom elements - and since the tables themselves didn't have to go away, I converted from the old ticket/sub history tables into the new ones. There were a couple of columns that didn't have spaces, and the plan is, if we need the information in those columns (which I doubt we will, but you never know) we'll refer back to the old history tables.

As for some of the required new columns, I made up some 'conversion' types of data for those - which is pretty similar to what we did when we actually converted.

It was pretty easy and smooth for us, but we had not highly customized our history already. So for smaller and/or less customized organizations out here, I'd definitely recommend making the switch. For you big beasties or highly customized people you might look at other options first!

- Heather

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:

Unknown said:

• 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.

This is a very old thread but as we've just moved from v10 to v11 to v12.5 in less than a year this is now a problem for us. We have several Extractions built on lists that no longer exists. I have some understanding creating other columns from the old ticket history to reflect in the new screens. I have no idea how this is done. What did some people do? Is there any way we can get the details to our IT Director so we can do the same. I don't understand why they would implement something that eliminates years of ticket history and not prepare people sooner. Of course, I want access to this legacy information through all upgrades. 

Any help and guidance would be appreciated. 

Thanks.

Heather, 

do you recall how the old ticket/sub history tables were "converted" into the new ones? We're now dealing with this after finally upgrading to 12.5 and it's a little daunting having to recreated hundreds of lists and extractions with new keywords. Is it too late for us to do some kind of conversion of our tables? 

Thanks in advance for replying. 

Unknown said:

[...] Of course, I want access to this legacy information through all upgrades. 

The network has recently been recommending a move to "standard" ticketing and package history tables, however this is not required. I made a group of custom SSRS tabs for this purpose, and until/unless the underlying standard history tables are modified to support one or more custom columns, we will continue to use these.

Don't let anyone tell you you have to abandon any of your data!

Re: "eliminates years of ticket history", it's quite possible that your old ticketing/package history tables are still present, but not currently displayed in the client. In this case existing list/extraction elements may still work, or could be easily re-created. (Having access to your database via SSMS will be extremely helpful in re: this issue, as it always is.)