How smart is the 'select' statement in QTP ?

[Deskin, Bob]

The SELECT in QTP is quite blunt. It does not affect the actual retrieval
and simply applies the selection conditions to the retrieved record complex.
There's no way to "stop" a select this way.

You may be able to fake QTP out. If you know there's only ever one active
record and it's the first record to be read, then you can create a "fake"
unique index in the dictionary. If you access via the unique index, QTP (and
QUIZ) "knows" that there is only one record and therefore only reads one
record.

I admit I haven't tried this technique for more years than I care to admit,
but it used to work like a charm. It was even written up in Supportlink a
very long time ago.

Let us know if it still works.

Bob Deskin              
PowerHouse Web Product Manager, Application Development Tools
Cognos Inc. 3755 Riverside Drive, Ottawa ON K1G 4K9 CANADA
bob.deskin@cognos.com (613) 738-1338 ext 7268


-----Original Message-----
From: Latimer, Richard [mailto:richard.latimer@airways.co.nz]
Sent: September 5, 2001 4:51 PM
To: PowerHouse List (E-mail)
Subject: How smart is the 'select' statement in QTP ?


Listland,


We make extensive use of date ranged records in our billing application - eg
we record that a particular aeroplane was owned by customer a from 1 January
1993 to 30 July 1997 and customer b from 31 July 1997 to < some date well in
the future>.  This record is indexed on the aircraft registration
(ascending) and then the applies from date (descending). Code in the
maintenance screens ensures that there is only ever one 'active' record per
aircraft.

Lookups to get the customer for a particular flight are done by linking to
the aircraft registration and then selecting the record where the date of
flight is between the applies from and applies to date.  There was an
implicit assumption that the 'select' would not need to continue scanning
the file after the 'first' record since it's conditions would have been
satisfied . . . however I suspect this is not the case.

To date this method has worked well and run times are reasonable but we are
looking to extend the technique to another lookup - in this case the runway
and weather conditions applicable at the destination airport of a flight.

Our most traded aircraft has had 30 owners in the 10 years we keep so even
in the worst case the select only has to plough through that many records.
The new scenario has the potential to generate that many per day! !


My question is whether the select statement is smart enough to realise that
the date is indexed / sorted and that it can stop looking after it has found
the right 'handful' of records. ?

Alternatively does anyone have a better idea for handling the lookup ?


We are PowerHouse 6.07 on DB2/400


tia

Richard Latimer
Wellington MIS Manager
Airways New Zealand
Ph +64 4 471 4744
Fax +64 4 471 0395











**********************************************************************
This electronic message together with any attachments is confidential. If
you receive it in error: (i) you must not use, disclose, copy or retain
it; (ii) please contact the sender immediately by reply email and then
delete the emails. Views expressed in this email may not be those of the
Airways Corporation of New Zealand Limited
**********************************************************************

= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.
This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender by
e-mail promptly that you have done so.  Thank You.