LT_NSCAN_ATTENDANCE

Does it have anything to do with people exiting the venue mid-performance, being scanned on the way out, and then perhaps re-scanned when they come back in?  I believe we do that for emergency purposes so that we have a constantly updated count of people who are actually in the venue.  Some people will arrive, get scanned in, but then have to leave early, or they exit the venue to get some refreshments, so we scan them out….those who do not come back are never scanned back in, those who come back in later are re-scanned as being in the venue.

Not sure…just some random ideas…

Penny Tabor

IT Manager

Midland Center for the Arts

Midland, MI 48640    

From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Simon Davidson
Sent: Wednesday, July 25, 2012 4:05 PM
To: Tabor, Penny
Subject: Re: [Tessitura Technical Forum] LT_NSCAN_ATTENDANCE

Thanks Caryl,

I have tried to track through like that and some seem to make sense, however there are other cases where it doesn't.  Case in point, The ticket_update on one line says 'Y', the exit_mode is 'N', but the exit_logged is 'Out'.  How can it scan 'Out' if it isn't in exit_mode?!?

Its important that I get accurate figures so that we can monitor attendance at General Adminission events so we don't go over our insurance / H&S occupancy limit...

Hi Simon,

Here’s a bit of technical background.

1.       When N-Scan first scans a ticket in, that barcode creates a row in LT_NSCAN_ATTENDANCE. For the purpose of future scans of the same barcode number, LT_NSCAN_ATTENDANCE, and the procedure that writes to it (LRP_NSCAN_TICKET_INFO) uses that original row as a “control record” to compare to. This row has a ticket_update status of “Y”, an exit_mode status of “N” and an exit_logged status of “N” (the default for any barcode).

2.       When you exit-scan a barcode that has already been scanned in, a new row is  created in LT_NSCAN_ATTENDANCE with a ticket_update status of “Y”, an exit_mode of “Y” and an exit_logged of “Out.”

a.       in addition to/ this new record, the procedure also updates  the exit_dt of the control record with the update_dt of the new row and sets the exit_logged status of the control record to “Out.”

3.       If the same barcode is scanned back in, then a new row is written to LT_NSCAN_ATTENDANCE with a ticket_update status of “Y”, an exit_mode of “N” and an exit_logged of “In.”

a.       At the same time, the control record – the original barcode – is updated with an exit_dt equal to the update_dt of the row for barcode being scanned back in, and its exit_logged status is changed to “In”.  

b.      It’s possible to see this happening by looking at the update_dt of the in/out scan records and comparing those to the exit_dt of the original scan:

select ticket_no,update_dt,ticket_ok,ticket_msg,ticket_updated,exit_mode,exit_dt,

exit_logged from lt_nscan_attendance

               where ticket_no in (select ticket_no from lt_nscan_attendance where exit_logged = 'Out')

               order by ticket_no, update_dt

This is why you can have a record that appears to have contradictory information (exit_mode = ‘N’ but exit_logged = ‘Out’). In short, what you want to look at is the exit_logged status – if it’s ‘N’, that was a ticket that scanned in and never left; if it’s ‘In’, it’s a ticket that was scanned in, left and came back; an ‘Out’ scanned in, left and was not scanned back in.

I should note that for attendance-counting purposes, reports in Tessitura don’t count scans out and back in as depleting or adding to the number attending. If you want “total scans in, net of scans out” you’ll have to do a real-time calculation of the number of unique barcodes with exit_logged status of ‘N’ or ‘In’ less the unique number of barcodes with exit_logged status of ‘Out.’  

Hope this helps!

Jonathan

Tom:

There’s more than just one attendance-recording table these days. T_ATTENDANCE is the “sanitized” version of attendance data- it records the actual, successful attendance scans. If you’re looking for the raw data that goes with every attempt to scan a ticket, the table you’ll want to query is T_NSCAN_EVENT_CONTROL. Everything that’s T_ATTENDANCE is in T_NSCAN_EVENT_CONTROL, but not vice versa.