It almost sounds like he could have saved you a lot of time by saying:

1)       Export all active links, filters, menus, etc for FORM
2)       Copy FORM to FORM-A
3)       Delete FORM
4)       Rename FORM-A to FORM
5)       Re-import all active links, filters, menus, etc.

Even with that said, below are some issues you might face:
1)       Your new FORM will have a different schemaid, which would mess up any 
direct SQLs to that schema, as well as any DB Views you've created using it.
2)       I think the WF would re-attach to the form if it has the same name, I 
don't think this goes off of schemaid, but I'm not really sure about that.
3)       I still don't think this would solve the issue

Thank goodness you did this on Dev first. Is the issue occurring in both dev 
and production? If so, check the name of the form to make sure there isn't an 
issue with it.

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company
________________________________
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Rick Cook
Sent: Monday, June 02, 2008 2:28 PM
To: arslist@ARSLIST.ORG
Subject: Re: Midtier Issues Turn Into Gross BMC Incompetence

** I'm assuming that all instances of FORM refer to the same form and form 
name.  So why would he, in step 3, rename FORM.old to FORM if in step 4, FORM 
is just going to be deleted anyway?  If that's true, and if this entire 
sequence has been accurately portrayed to us, it shows little thought or 
experience.  I would deal with it at that level.

Rick
On Mon, Jun 2, 2008 at 12:15 PM, LJ Longwing <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> wrote:
Yea...I can understand up to point 6....but after that is just weird and
definitely shouldn't be done on a production server.

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 (This is your actual
form...with data and stuff)
3. Now rename <FORM>-new to <FORM>. (this puts a blank form into place using
the original form name)
4. Delete the form <FORM> (removing blank form)
5. Rename <FORM>-old to <FORM> (rename original form from its new name to
its original name)
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>

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Paul 
Blasquez
Sent: Monday, June 02, 2008 12:37 PM
To: arslist@ARSLIST.ORG<mailto: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<http://www.arslist.org>
Platinum Sponsor: www.rmsportal.com<http://www.rmsportal.com> ARSlist: "Where 
the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at 
www.arslist.org<http://www.arslist.org>
Platinum Sponsor: www.rmsportal.com<http://www.rmsportal.com> ARSlist: "Where 
the Answers Are"

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to