QTP locking with an RDBMS

[EDISR@detroitedison.com]

G'day all 
 
We have an enigma with PH QTP 6.10e.  The problem is when running a QTP that 
scans a large table or takes a few minutes, QUICK screens reading that table 
get locked up.  QUICK is running in CONCURRENCY mode (Rdb 4.1 is
OPTIMISTIC). 
 
According to the manual, the use of SET FILE filename OPEN READ SHARE should 
delay the file lock on 'filename' until the OUTPUT phase.  'filename' is the 
primary file.  Using multiple sessions for QTP, QUICK, RMU and SQL, we were 
able to determine the SET FILE statement had no effect on locking.  The ONLY 
way we could reduce the locking to an acceptable level was to use COMMIT AT
n 
RECORDS (or COMMIT AT UPDATE) where n was a compromise between QTP
performance 
and the length of time the screen would have to wait. 
 
Does anyone have experience with this issue?  If so, how did you deal with
it? 
 Is there a bug in QTP 6.10e that prevents forcing CONCURRENCY mode? 
 
I wait with baited breath ;) 
 
Robert Edis (Blue) 
Technical Consultant 
Michigan, USA 
(VAX/VMS, ORACLE Rdb, PowerHouse 4GL)
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.