Take a look at ASI:AEO:Delete_BMC_Dependancy_Get_ReconLogin_923. When I had to rebuild my BMC_Person table I had to turn this off.
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Hodgdon, Paul Sent: Thursday, February 07, 2013 6:07 AM To: [email protected] Subject: Re: Reconciliation for BMC.Core:BMC_Person ** Roger, Do you mind explaining a little bit more? I am unclear as to what you are referring to. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Roger J Sent: Thursday, February 07, 2013 8:59 AM To: [email protected] Subject: Re: Reconciliation for BMC.Core:BMC_Person ** I have seen this before and the workflow that popultates the Person Record when a CTM:People record is created or modified is a more efficient way to stop this. -----Original Message----- From: Hodgdon, Paul <[email protected]> To: arslist <[email protected]> Sent: Thu, 7 Feb 2013 8:53 Subject: Reconciliation for BMC.Core:BMC_Person ** I was wondering if anyone knows if it is ok to turn off the reconciliation job that associates people to assets via the Bulk Load Sandbox operation. We do not have a CMDB at this point and are using the java arapi Data import to create and modify records in CTM:People. What I am seeing is that on modifications the BMC.CORE:BMC_Person table requires additional fields that CTM:People does not (see error below). When we did perform some bulk modifications of people records the database server seemed to max out CPU usage during the reconciliation event. I was hoping to just be able to avoid this event from running, does anyone have any suggestions? I just want to be able to keep CTM:People up to date. ERROR (326): Required field cannot be blank.; BMC.CORE:BMC_Person : ShortDescription Paul Hodgdon ITSM Enterprise Manager University of New Hampshire _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
