I'm not the one working directly on this so I've just been kept in the loop but am not 100% involved with what the cause is, so we're not sure if it was an issue with the 8.1.2 install, the way our consultant updated the Status Reason field, or some other thing that we aren't aware of. As a result, BMC told us that we can fix this specific view by going into it via Dev Studio and updating it to get Remedy to update the view and all is fine. Since we're leaning toward 8.1.2 being the culprit, we've asked them for a way to identify and fix these issues immediately rather than going into a bunch of forms in base development mode and saving them. Additionally, we don't know exactly how to spot when these types of errors occur, or even what caused them, so I'm not comfortable risking a larger problem in production since we don't know what triggers the problem.
That being said, I've done things directly in SQL with the guidance of BMC in the past but in this case they're being more vague and telling us to speak with our DBAs about writing a script instead of them giving us a specific script that they would support in case things go south. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Friday, December 12, 2014 12:44 PM To: arslist@ARSLIST.ORG Subject: Re: Deleting Overlays - Nightmare ** It should not change the owner name if you login to SQL using the credentials of the AR System database owner which by default if you have not changed that should be ARADMIN. I agree they used to recommend not to do anything directly using SQL, so I didn't for the most part do it & would have stood on the path of caution as well if I was told that. Having said that, if it is just a view that you need to recreate or rebuild, it will not hurt the system. Despite BMC's cautionary advise of not doing directly anything to the DB, I have broken that rule in the past myself as that was the only solution to a problem I had back in the days on Sybase too (where the AR System views on inner joins were not optimized). The fallback however of doing that is that this view will then have to be forever manually maintained. Any change on the form behind which that view is, will impact that view and the AR System will attempt to recreate that view. Then you would need to manually touch it again. All I am saying is that if you do not happen to come at a more agreeable solution, it is not the end of the road and you could bring the idea of manually creating that view back on the table. Just beware that it would then need manual maintenance after any change to the form that view belongs to. You could end up having problems if you do not pay attention to that dependency. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: Friday, December 12, 2014 9:36 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Deleting Overlays - Nightmare That is exactly why we pushed back on them because it's not what we would normally be told. I think the SQL just changes the owner name of the objects so it shouldn't harm anything, but I also don't understand why the 8.1.2 installer would have potentially changed them in the first place. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing Sent: Friday, December 12, 2014 8:32 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Deleting Overlays - Nightmare ** Well that's certainly interesting...I've never heard BMC recommend doing ANYTHING directly at the DB via SQL. On Fri, Dec 12, 2014 at 7:28 AM, Pierson, Shawn <shawn.pier...@energytransfer.com<mailto:shawn.pier...@energytransfer.com>> wrote: ** We recently ran into an issue on 8.1 where BMC told my colleague that using the Class Manager is no longer the recommended way to modify the underlying forms, in our specific case it was to add a few new Status Reason values to Base Element. Additionally, with 8.1.2 our views were corrupted somehow on at least Base Element, where we've been instructed to directly update the views manually via SQL. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of LJ LongWing Sent: Friday, December 12, 2014 8:05 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Deleting Overlays - Nightmare ** Aditya, Yes, Misi is 100% correct. When adding attributes to CMDB you are supposed to do it through the class manager, which manages all of the forms and joins and such. Overlays are not supported and will need to be deleted...which means you will loose your custom attributes, but you'll want to take a backup and restore them after the upgrade and the attributes are added in 'properly' On Fri, Dec 12, 2014 at 5:30 AM, Aditya Shrivastava <iadity...@gmail.com<mailto:iadity...@gmail.com>> wrote: ** Hi Claire and Terry, While upgrading Atrium Core from 7.6.04 to 8.1.01, even I am getting this error on installer that (X) Following forms have overlays created. Atrium install needs this overlay to be deleted. Please delete the overlay for following forms before proceeding with upgrade: BMC.CORE:BMC_BaseElement BMC.CORE:BMC_BaseElement:AUDIT BMC.CORE:BMC_ComputerSystem BMC.CORE:BMC_Equipment We do have custom attributes for some of the classes including those mentioned above but I believe this should be preserved. Please suggest how to correct this error? Also, we plan to upgrade ITSM after this. Should I be prepared to see such errors there as well? Please suggest how to take it forward. Regards, Aditya On Tue, Oct 28, 2014 at 4:06 AM, Terry Bootsma <tboot...@objectpath.com<mailto:tboot...@objectpath.com>> wrote: ** Claire: The fact that your prod db was changed when you deleted your overlays in Dev Studio when connecting to RemTST tells me that maybe you didn't update your database connection from your RemTST VM to point to the test database? I know it is pretty obvious, but that is the only reason I could think it would happen. But, why you should have to delete your overlays is confusing (unless your overlays were corrupt ? ) . That's the whole purpose of overlays. Terry ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Sanford, Claire Sent: October-27-14 6:06 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Deleting Overlays - Nightmare ** I'm trying to do an "upgrade" on a new VM server. Did ARS 7.6.04 PS3 to ARS 8.01.03. Just a few hiccups. Going from Atrium Core 7.6.04 SP3 to SP5 has been the nightmare. Once that is done then I'll be doing the rest of the ITSM stuff which is heavily overlayed! I have had the DBA copy the Prod DB to a new space RemTST and the installer for the CMDB told me to delete the Overlays for some of the "BMC.CORE:" forms. When I did this using Dev Studio (after confirming with the support dude), the tables went from "Overlayed" to "Unmodified". On RemTST. It also happened on RemProd. The Production Database. I was not even logged into the Prod server in Dev Studio. All those forms now show Unmodified instead of Overlayed. Because the fields were entered using the class manager, my fields should still be there. There is a backup from this morning for RemProd. The DBA looked at the database on the Oracle level and said that the table ID numbers I gave him are there. They do not show up when I look at the DB via ArUtilities. Any Ideas? I have not had to delete an overlay since going into production and am concerned about the ramifications. All I have gotten from BMC support for all of my questions regarding this upgrade have been copies of KB articles instead of just a yes/no answer to my direct questions. Once Again! Overlays do not make patching and upgrading easier! Claire _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_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here<http://www.energytransfer.com/mail_disclaimer.aspx>. If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here<http://www.energytransfer.com/mail_disclaimer.aspx>. If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
