Wow. This whole step by step procedure really has many issues: 1. Why are they asking you to create copies and remove and replace the form on the server when this sounds like a Mid Tier issue not a server issue since you don't have the problem with the User client? Wouldn't it have made sense to troubleshoot your issue with the mid tier cache or tomcat (or with whatever is hosting the web on your Mid Tier server)?
2. Why would you be creating a separate iteration of the form and backing up the original form and then in addition to renaming the separate iteration to the name of the original form you would delete the original form and create the form from scratch? It seems like they are having you do too many things at once. Shouldn't they have you test one thing (seeing if it is an issue with the formname itself) and then if that does work try creating a form with that name from scratch to see if that resolves the issue? Just not good advice to troubleshoot this issue (despite the fact that even the notion of troubleshooting a Mid Tier issue with rebuilding your form is crazy IMHO). I would definitely escalate that issue to your BMC rep about this. Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez Sent: Monday, June 02, 2008 2:37 PM To: arslist@ARSLIST.ORG Subject: Midtier Issues Turn Into Gross BMC Incompetence Hello, I'm a little upset here, as I have received instructions from BMC, that had I carried them out blindly on my production server, would have completely wiped out any workflow and data I had not backed up, and with no warning from BMC. I would like to share these instructions here, and get opinions as to whether I am totally misunderstanding the instructions, or if I was given incomplete and dangerous instructions by an incompetent BMC tech. The problem was, originally, that when my form was called from the midtier via a table or results list, the browser would display the form as blank even though a specific request id was requested. So, double click the ticket, window opens, form is blank instead of filled in with that ticket's contents. All workflow works fine in the user client. So, after minor troubleshooting with BMC they finally request the .def file, I send it. They get back to me with the following instructions (object name replaced by <FORM>): 1. Go to the Admin tool and open that form <FORM> and Save as that form with the different name e.g. <FORM>-new 2. Rename original form <FORM> to <FORM>-old 3. Now rename <FORM>-new to <FORM>. 4. Delete the form <FORM> 5. Rename <FORM>-old to <FORM> 6. Verify all the Active Links/Filters point to <FORM> 7. Export the *.def file of <FORM> 8. Delete the form <FORM> 9. Create new form & name it <FORM> 10. Verify all the Active Links/Filter point to <FORM> Now the issue with this, and thank goodness I did this on my development server first, is that at step 8, YOU DESTROY ALL YOUR DATA AND WORKFLOW. Making steps 9 and 10 irrelevant. Even given the fact that I could have implied that at step 7 I should have exported the entire workflow for that form, there is still no step that says back up your data, and there are no steps explaining importing back your workflow and data. Please give me your points of view on this situation because I am trying to not write a scathing email or make a hostile phone call right now. ____________ Paul Blasquez Senior Network Engineer/Remedy Developer | Desk - 408.360.5220 | Cell - 408.627.5714 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" Please consider the environment before printing this e-mail. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
