QTP migration questions

[Ken Langendock]

Ok from what you have told me here, my suggestion
would be to keep QTP running. Learn basic SQL and
replace all your access statments with cursor. First
off your team will be learning SQL and still using
their experience in powerhouse. They should also be
learning VI to allow them to float from one Unix line
to another....believe me, Qedit (or whatever you use
is obsolete) and you can get VIM for the PC.

Then comes the fun part. If after you have implemented
cursors and did not get enough of a performance
improvment from doing this (which I doubt, I used to
call Turbo Image...Turtle image after moving to a
unix/oracle env), you can start moving some of the
business logic into the database. Ie. Integrity
triggers (if I add a record here, it needs to update
that field over there in that file), this should
remove some code. Next add Views, you should be able
to remove more code from this and finally stored
procedures. Here is where you will take the most
amount of time and remove the most amount of code from
your QTP processes.

Hope this helps...this is my approach.
Ken




 --- Pat Shugart <ShugartP@trinity-health.org> wrote: 
> Good points, Ken.
> 
> We're not replacing Powerhouse. We're keeping QUIZ
> already and trying
> to figure out whether or not to add QTP.
> 
> Our decision to continue to use QTP comes down to
> two things: Timeline
> and performance.
> 
> If we convert QTP to <whatever>, we do not have the
> resources to do it
> in-house and maintain our timeline. So, each QTP
> process will have to be
> documented for a re-write for the company doing the
> re-write. We do not
> document each individual process in our jobs, only
> the overall process
> being performed for the business. So, we'd have to
> go into each QTP and
> write down what it does. That alone will impact the
> project schedule.
> 
> Ken, when you write that moving more functionality
> into the database
> will improve performance, what do you mean by that?
> Placing business
> logic into things like stored procedures? I'm not
> Oracle-savvy, so
> please excuse my ignorance. I have been promised by
> the time the project
> is complete, I'll know more about Oracle than I'll
> ever care to. :)
> 
> Thanks,
> /pat
> 
> >>> ken.langendock@rogers.com 1/12/2005 8:51:54 AM
> >>>
> I guess it comes down to what your timeline is:
> Are you replacing Powerhouse completely or just
> thinking about replacing QTP? 
> 
> I work for a company that sells multi-million dollar
> powerhouse product and have improved QTP using
> cursors. There are some cases where moving more
> functionallity into the database improves
> performance.
> But this may only become appearent after being in
> production for a while.
> 
> If you are just worried about qtp. Convert the app
> and
> add cursors to every qtp process. You will see an
> incredible performance improvement.
> 
> Ken
> --- Pat Shugart <ShugartP@trinity-health.org> wrote:
> 
> > I'm sorry. Forgot to mention we'll be migrating to
> > an Oracle database
> > environment located on the HP9000 (HP-UX).
> > 
> > >>> "Joe Boyle" <atla38@dsl.pipex.com> 1/12/2005
> > 8:38:09 AM >>>
> > I can't see what database you are using but memory
> > tells me that Oracle
> > was
> > quite slow on Mpe, so, in my opinion, this will be
> > faster on the 9000
> > without any changes.
> > 
> > As always, choose will be equivalent in
> performance
> > to sql declare
> > cursor
> > syntax, but qtp 'select if' syntax will always be
> > slower that anything
> > that
> > is processed within the database e.g. 5 minute
> runs
> > reduced to 5
> > seconds
> > when using cursors.
> > 
> > Regards, Joe.
> > 
> > This e-mail and all information contained in it is
> > confidential and may
> > be
> > legally privileged. If you are not the intended
> > recipient, your access
> > to
> > this e-mail is unauthorized. Any use,
> dissemination,
> > distribution,
> > publication or copying by you of this e-mail or
> any
> > of the information
> > contained within it is prohibited and may be
> > unlawful. Do not open any
> > attachments, delete it immediately from your
> system
> > and notify the
> > sender
> > promptly by e-mail that you have done so. The
> > content of this e-mail
> > and any
> > attachments sent with it may have been altered
> > without the consent or
> > knowledge of the author.
> > 
> > -----Original Message-----
> > From: powerh-l-admin@lists.sowder.com 
> > [mailto:powerh-l-admin@lists.sowder.com] On Behalf
> > Of Pat Shugart
> > Sent: 12 January 2005 13:03
> > To: powerh-l@lists.sowder.com 
> > Subject: QTP migration questions
> > 
> > Hello all,
> > 
> > We're an Amisys shop in the final planning stages
> of
> > our migration from
> > the
> > HP3000 to Amisys Advance on an HP9000. One of the
> > decisions we need to
> > make
> > is what to do about QTP.
> > 
> > Choice #1: Convert QTP code to SQL (we use PL/SQL
> > for other apps). As
> > I
> > understand it, performance is the greatest
> advantage
> > of doing this.
> > The
> > "disadvantage" is that we have to rewrite all of
> our
> > QTP code (and
> > document
> > it!) and it would take quite some time, as we have
> > approximately 85
> > QTP
> > processes of varying degrees of complexity.
> > 
> > Choice #2: Continue to use QTP on the 9000. The
> > advantage is that
> > relatively
> > few changes will need to be made to our code and
> the
> > migration/test
> > period
> > can be shortened. The great unknown is
> performance.
> > Is it (nearly) as
> > fast
> > as SQL code? For you HP3000 users, I draw a
> > comparison to what happened
> > to
> > Suprtool. I understand it is not nearly the same
> > tool it was on the
> > HP3000.
> > I haven't been able to find any sort of comparison
> > docs between the MPE
> > and
> > HPUX versions of QTP. 
> > 
> > I would appreciate both real-world and theoretical
> > thoughts regarding
> > our
> > choices. Please don't call or email me about
> > migration "solutions".
> > Most of
> > those decisions have already been made. Although
> > alternatives to the
> > choices
> > above are welcome...
> > 
> > This may have been a duplicate post * my first
> > attempt was rejected
> > when I
> > sent it to the previous listserv address. Sorry.
> > 
> > Thanks in advance,
> > 
> > 
> > `....`....`....`....`....
> > Pat Shugart
> > Trinity Information Services
> > 34605 Twelve Mile Road
> > Farmington Hills, MI 48331
> > 248.489.6123
> > 248.488.9195 (fax)
> > 
> > 
> > 
> > = = = = = = = = = = = = = = = = = = = = = = = = =
> =
> > = =
> 
=== message truncated ===