Jump to content


Hornbill Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


SamS last won the day on November 23

SamS had the most liked content!

Community Reputation

70 Excellent

About SamS

  • Rank
    Senior Member

Profile Information

  • Gender
  • Location
    Hornbill Offices

Recent Profile Visitors

674 profile views
  1. Hi @Darren KIng, A new release incorporates the fix for this: https://github.com/hornbill/goDb2HUserImport/releases/tag/1.2.3
  2. Hi @Darren KIng, We tested the original executable with 20.000+ entries and it got well beyond the 100th user your log file suggests it ended on. That being said, we did find a place to optimize it and have released it (as version 1.2.2) on github [ https://github.com/hornbill/goDb2HUserImport/releases ]. I have also updated the wiki instructions to emphasize the SQL best practice to specify fields in the SQL SELECT statement
  3. Hi @Darren KIng, Though admittedly, I haven't tested the script with more than 10.000 entries, I would first be wondering what is returned with your query results. In your example, you are running SELECT * on a view, this could potentially bring in more results that actually mapped by yourself. Some of those extra fields might be longvarchar and/or blob fields which would use a lot of RAM to store. IF they are not being mapped, then I would ensure those are not included in the results. Could you please run SELECT for each field you are actually using - or confirm to me here that the result does not contian many more (longvarchar/blob) fields ? eg: SELECT objectID, siteType, ... FROM view_#####
  4. SamS

    % requests within resolution SLA

    That gets my "Thumb's up"
  5. SamS

    % requests within resolution SLA

    Hi Lyonel, It mostly depends on WHAT information you want to get out: Option 1 will not, I think, give you a sensible number; it compares calls logged in a period with an amount of calls breached within that same period. Please note that some of these breached calls might have been logged before the period. The percentage generated would imply, but is not, the percentage of calls meeting their SLA logged within the period. Option 2 is where my vote would go for %breach (one is comparing resolved calls). Alternatively, one can report on percentage of breached calls currently open. One can also report on: out of the amount of calls logged within this period, how many have breached (and transform it into a percentage). Please note that calls could still be open and (about to) breach. OR: out of the amount of calls logged within this period, how many of the resolved calls have breached. Needless to say, this percentage will vary over time as more calls from that period get closed. The other thing to keep in mind is the various SLAs. Tallying P1's and P3's in the same heap might give a very skewed picture: eg 99% meeting of SLA could hide 100% missing of P1's Anyhow, I hope I have given you some food for thought. Sam