Hi,
We did a bulk MHM (Morris Hargreaves McIntyre culture segmentation) survey last year prior to fully implementing MHM here at SOH and have 4K segmented constituent data in CSV. Normally when constituents take the survey on the MHM server the data flows automatically via the API into the Tessitura MHM local table. We are looking at ways to get the CSV data into the local table and wondering if anyone else has done this? Each row of the table has a unique ID and we want to be sure manually taking 4K rows to upload these responses won't clash with any data coming in from the MHM server for us or our consortium partners also using MHM.
Appreciate any feedback.
Thanks,
Chuck Buchanan, Sydney Opera House
I haven't done this exactly, but it depends exactly what you're importing. Is it their complete survey results or just their single MHM category?
If its just a single value, and you have a customer ID attached to all of these people, then it should just be a matter of importing the data for those customers who don't already have an MHM value. So you could import the CSV into a holding table, then run a delete to get rid of those rows where the customer ID already has an MHM value in your current database. Then import the rest.
Or if you don't want to lose anything, you could import the lot into a staging table, then in a script, import everything into a #tempory_table, delete the rows, import the rest, etc.
Does that make sense?
Hi Matt,
The CSV file of MHM data has all of the proper fields needed for the LT_MHM_SURVEYRESPONSES Tessi table including the constituent ID. None of the constituents exist yet int he table, I didn't mean "clash" in the sense of duplicate constituents. But rather want to make sure that if we manually upload the data to the table and take 4K rows that the data that flows automatically from MHM's system wouldn't clash by trying to take those same rows (as each row has a unique row ID).
Thanks for the help :)
Hi Chuck
The LT_MHM_SURVEYRESPONSES.id column is an identity column, so it looks after its own sequence - so you should be safe - so long as you set the [organisation_id] value correctly to soh's id, and don't trip over Martin's rows or mine. ;-)
Ken
Thanks, Ken! I should have just called you :)