Yes you are correct, except that he renamed FORM.new to FORM, then
deleted it.
 
I believe he was attempting to, for lack of a better term, "shake things
loose" by running file writes on every conceivable storage location in
the backend.
 
The truly criminal step is step 8, as I said before.
 
And yes, this is a direct copy-paste from his emails to me.  Here is
another (referencing the current "solution"):
 
"Did you tried the latest solution provided? it shouldn't cause any kind
of losss."
 
He states that because I had stated that it looked like I was going to
lose data.  I did not expect to also lose workflow.
 
 
Thank you everyone who replied confirming my conclusions.  I am
currently escalating with the manager provided at the bottom of his
email and our reseller.
 
-Paul

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Monday, June 02, 2008 12: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]>
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:[EMAIL PROTECTED] On Behalf Of Paul Blasquez
        
        Sent: Monday, June 02, 2008 12: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"
        
        
________________________________________________________________________
_______
        UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
        Platinum Sponsor: 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