I hate those types of issues and wish you good luck. That sounds like a problem with the core functionality, and the BMC support rep should have involved Engineering by now.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez Sent: Monday, June 02, 2008 3:38 PM To: arslist@ARSLIST.ORG Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence Thank you for the suggestions, unfortunately there is no smoking gun in the logs. It happens not only on a table drill down but also on a results list drill down. The only time it works as expected is when there is a results list on top of the form, as in a standard search. When you highlight a ticket there, it populates the form underneath. However, if you double-click the same ticket from the same results list, the new window fails to populate the data, and does not throw an error in either the server or midtier logs. BTW, I have finished importing my workflow and form back into development from production and the issue still exists. So, whatever write operations he hoped would clear the issue obviously did not work, as it has been blown away and restored and is still exhibiting the same behavior. -Paul -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn Sent: Monday, June 02, 2008 1:15 PM To: arslist@ARSLIST.ORG Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence I love a good rant against BMC Support as much as the next person, but I'd like to see your problem resolved too. Can you give us more information that might help determine what the problem is? To start, are you using the Drill Down on the Table Field, or are you trying to open that record with an Active Link? If it's via an Active Link, can you send us more information on the Open Window command? If I was in your shoes, I would run Active Link logs and try to reproduce it in both the User Tool and on the Mid Tier, then compare those log files and see what's happening. My guess would be that something potentially happens in one of those few areas where there is a difference in the two, such as how Display/Windows Loaded for the Execute On are different, or perhaps the timing works differently and some workflow that has a lower execution order takes longer and a later one does it's action first, or something weird. Still, it should be something you can figure out by looking at the logs from both. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Paul Blasquez Sent: Monday, June 02, 2008 1: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" Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
