<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-01-02T16:15:57Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-10-17T21:10:47Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Verified Das list is deleted and time required to import isf  and detect das is much less with post patched versions of datapro  when performing isf import .

Time prepatch  2:23 seconds

Time post patch 5-6 seconds 


Tested with dp versions 4 0 1072,4.1.473.49733 and 4.2.190.49739.
compared to prepatched version 40 729 


1.Imported a large  group of das  (attached ) 
2. Created an ISF import file  using a SPS and sensors on it .
3. In test setup choosing import isf file  and runninghte import in each version of datapro and recording the time differences until it completed.




</Comment>
    <StatusString>Closed</StatusString>
    <TimeStamp>2023-10-17T21:10:13Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Closed</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-08-10T18:14:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-08-10T18:14:23Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-08-10T18:10:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-08-05T04:07:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2023-08-01T18:15:49Z</TimeStamp>
    <ReleaseNote>now ISF imports will delete hardware before importing</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Jerry Lawrence</User>
    <Comment>49258 is 4.0; 49259 is 4.1; 49260 is 4.2</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2023-07-27T00:03:35Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Jerry Lawrence</User>
    <Comment>To test:
Execute a ISF import and ensure that it works correctly.

should take less time to import post patch with a large database (specifically lots of DAS) than pre-patch

grab list of das prior to import and after import, verify that any das are deleted which are actual DAS and not in the import, and any Prototype das aren't deleted.

should be able to open up any existing test setups that had DAS assigned before, but they will now not have DAS assigned, but it shouldn't crash, same thing with groups, the channels should still exist, just no hardware assigned.

maybe test that there are no adverse affects if there's a test setup with a level trigger assigned to a das and the import deletes that das.

same thing with calculated channels</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-21T23:34:10Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Jerry Lawrence</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-21T15:36:19Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-18T22:54:07Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-07-18T18:33:39Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-07-11T14:10:26Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-02-01T22:06:18Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-01-18T17:29:02Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2023-01-18T17:28:53Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2022-08-23T20:43:07Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2022-08-12T23:00:11Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>this is way_way slower in 3.3, this is likely an issue that's already been fixed in 4.0 ...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2022-08-10T21:50:55Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>don't really see the behavior in 4.0 currently ...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2022-08-10T18:48:17Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2022-08-09T21:03:20Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2022-08-09T20:58:13Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2022-07-26T23:48:45Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2022-06-28T18:16:59Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2022-06-17T19:49:21Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>with a large DB import an ISF - large delay seen during commit, if you do the same on the blank db, it's fine.
 
see also case 27059
 
 
 
#10539 INTERNAL | DataPRO | Slow ISF Import | HW Database
 
 
 
 
Submitted
 
June 17, 2022, 12:17
 
   
 
Received via
 
Web Form
 
   
 
Requester
 
Nathan Brown &lt;nathan.brown@dtsweb.com&gt;
 
 
 
 
CCs
 
Chad J Ivan &lt;chad.ivan@dtsweb.com&gt;, Chris Balogh &lt;chris.balogh@dtsweb.com&gt;, Mike Beckage &lt;mike.beckage@dtsweb.com&gt;
 
 
 
 
Status
 
Open
 
   
 
Type
 
Problem
 
   
 
Priority
 
Normal
 
   
 
Group
 
Support
 
   
 
Assignee
 
Dan McFadden
 
 
 
 
 
Internal Ticket
 
Yes
 
   
 
Ticket Source
 
Help Center
 
   
 
Product Family
 
Software::DataPRO
 
   
 
Software Version
 
3.1.672
 
   
 
Problem Source
 
Unidentified
 
   
 
Current Department [Optional]
 
Tech Support
 
 
 
 
 
Nathan Brown June 17, 2022, 12:17
 
 
GM Barrier ISF import took ~20 minutes on 2022-06-15 with DataPRO 3.1.672
  
 Narrowed problem down to long database calls after all hardware pinged and was queried.
  
 Deleting all hardware from the Data Recorders tab and importing the same ISF again brought the time down to ~4 minutes. 
  
 Performance was similar in 3.3 before/after hw deletes as well. To simplify, no logs from 3.3 here.
  
 Attached are the DataPRO db, ISF, and logs which include at least 3 sessions showing the long waits which improve in the final run.
  
 Very short term, Daniel will delete the hw from Data Recorders if necessary but we'd like to improve this.
  
  
 
 
 
 
Nathan Brown June 17, 2022, 12:19
 
 
I suspect if we could improve the hw queries it will speed up discovery in all areas, not only ISF import. Is this enough info to proceed with manuscript ticket and work?
  
 Big thanks Dan for support today!
  
  
 
 
 
 
Dan McFadden June 17, 2022, 12:42Internal note
 
 
should be enough, I'll update the ticket once I'm done creating the manuscript item for it.
 I'll assume we should probably address it in 3.1 as well (the version they are currently using)
 
 
 
 
 
Support Software by Zendesk</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2022-06-17T19:49:21Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>