4 Replies Latest reply on Jun 14, 2016 5:21 PM by Darris Friend

    Query for active customer outage in Responder?

    Darris Friend

      How do I query Responder tables to identify an active incident? We are converting our CIS extract process from an Oracle environment to a SAP HANA environment. During the nightly refresh of the RX_Customers table I don't want to overwrite an active outage for a customer. Do either of the fields Time_Disconnect or Connect_Status need to be queried (IS NOT NULL??) to verify an outage for that customer?

        • Re: Query for active customer outage in Responder?
          David Miller

          Darris,

           

          You'd actually need to query the RX_LOADPOINTs table, specifically the CUSTOMER_ACCOUNT field.  If a customer's account number is found in that table, they are involved in an active incident where their power is out.  These are the ones you should skip.

           

          The Time_Disconnect field is for nonpayment situations and comes from your CIS.  The Connect_Status is the account status from your CIS system.  Responder does not typically modify any of the fields in the RX_CUSTOMERS table unless you write something custom to do it.

            • Re: Query for active customer outage in Responder?
              Darris Friend

              Thanks for replying David. If a customer is involved in an active incident, based on the row in RX_LoadPoints, is it permissible to truncate then update RX_Customers with data from the CIS while that customer is in an active incident?

                • Re: Query for active customer outage in Responder?
                  David Miller

                  Do you have a test system to try this out first?

                   

                  We have our CIS update skip any customers who are involved in an active incident just to avoid the possibility of corrupting out the incident.  And I honestly don't think your database will let you fully truncate that table because it should have row locks on those customers involved in an active incident.

                   

                  Our process for RX_Customers is that we have a customer information table that participates in a view that mimics the RX_Customers table (ours is called RX_Customers_View).  The customer info table is truncated and repopulated nightly, which "refreshes" the view.  Then our CIS update process does a comparison between the RX_Customers table and the RX_Customers_View, updating RX_Customers with the deltas.  If the updater finds a record that belongs to an active incident, it will skip it and keep updating other records.