4 Replies Latest reply on Oct 10, 2017 7:37 AM by EquumStercore

    Additional Contact being changed in History

    GZimme Apprentice

      GMPE 2016 / 2017.


      I have a client who is now on 2017.1.0.384 and was on earlier versions of GMPE.


      They don't know when this last happened but stated when they add a new Additional Contact (ie Suzie Q) and then Delete an old Additional Contact (Joe Shmoe) that all the Additional Contacts with Joe Shmoe would get changed to Suzie Q.  I've never see or heard of this before.  Was this a bug and now fixed or is this something new?



        • 1. Re: Additional Contact being changed in History
          John Neighbors SSMMVPGroup



          I hope I can explain this clearly enough.  I've had to deal with this often through the years, due to poor design on the part of GoldMine History, in my opinion.  However, it's not quite what you describe, although I suspect I'm hitting the nail on the head.


          The issue isn't so much with changing ADDITIONAL CONTACTS, but rather, shows up when the PRIMARY CONTACT on a record is changed, and THEN only on CERTAIN History records.


          This has to do with...


          1) How History records store the "contact" name associated with the History.


          2) The fact that sometimes History records do NOT store a contact name at all.


          3) And...how GoldMine handles the situation noted in item 2) above.


          In looking at my own GoldMine system, I'm finding the NEWEST of such History records are dated 2015 and older.  Therefore, newer versions of GoldMine (I'm on the absolute latest version of 2017.1), may avoid this issue by simply not creating History w/o a contact name associated with it.


          However, my current version of GoldMine will still behave this way, based on old History in our system.


          If you're familiar with the silly (oc:) notation used in the REF field of the CONTHIST table, that's what this is in reference to.


          If that notation references a value, for example "Whatever (oc: John Neighbors)", then GoldMine will NOT exhibit the behavior you describe.


          However, if it does not have a value with this notation, for example "Whatever (oc:)", then  it MAY exhibit the undesired behavior. (I've seen cases where it did not, and never paused long enough to figure out the difference.)


          Here is an example:


          I ran this SQL query in my GoldMine:


          select top 100 * from conthist where ref like '%(oc:)%' and ref not like '%(oc:%(oc:%' and isnull(accountno,'') <> '' order by recid desc


          I then focused on one contact record that came up.  Before I changed the Primary Contact name, all looked good.  I failed to grab a screen snippet, but there were a couple of the History showing a BLANK "Contact" name, and all others where showing the same name.


          I then switched the primary contact name to "Bubba" (I know, I'm real creative), and this is what I saw:


          I blurred out the real name, for privacy sake, but everywhere you see Bubba, used to say the same as the name that is blurred out (because it was the Primary Contact's name).


          I then changed the primary contact name to "Tony", and got these results:



          The bottom line:


          For any History records that, behind the scenes, do NOT have the contact name stored in the (oc:) notation in the REF field in CONTHIST, then whomever is the CURRENT Primary Contact name MAY (often WILL) show up on the History tab.


          This is clearly nasty behavior. Hope this feedback helps.

          • 2. Re: Additional Contact being changed in History
            John Neighbors SSMMVPGroup

            By the way, here is the text I submitted to GoldMine Tech Support in March 2016 of a SIMILAR (but different) issue related to this silly (oc:) notation reality (just for reference):


            This client has lots of additional contacts on each GM primary contact record.


            Some of them have SIMILAR names in the sense that the names START OUT with x number of characters being the same (e.g. Chris Smith, Chrissy Weston, etc.).


            If they happen to create history records that have fairly long REFERENCE values, then the silly way the contact name is stored along with the REF field in the CONTHIST table, means that the UNIQUE Additional Contact name cannot be determined.



            Use THIS reference:  This is a really really long reference line on this history record AND

            On a record with two additional contacts named:

              Alicia Somebody

              Alicia Sweeney


            Pick Alicia Sweeney as the contact on the HISTORY record.  Looking behind the scenes, shows this as the REF field:


                This is a really really long reference line on this history record AND (oc:Alici


            On the History tab, this History record is showing Alicia Somebody, NOT Alicia Sweeney, as we selected.


            I clearly see the issue is a DESIGN problem and how the History stores the contact name in with the REF field, but that's not a good explanation to offer this client that clearly sees the software as showing the WRONG Contact name.



            Just thought I would share, because it is so similar in nature.

            • 3. Re: Additional Contact being changed in History
              GZimme Apprentice


              THANKS for the reply and info.


              My practice without knowing these issues was to mark the Addtl contact as "No longer with the Company" in the reference field and blank out email address etc but keep the record.  I would then add whatever additional contacts as needed.   I have swapped many Addtl Contacts with Primary over the years with no issue as far as I can tell.

              • 4. Re: Additional Contact being changed in History
                EquumStercore Apprentice

                It is this exact type of thing that should be high on the fix list rather than the useless nonsense that development time is spent on so often.