Probs in 8.40D

[Joe Boyle]

what do you see in the dbaudit file dbaudit.txt, it might give you an idea
of where to go next. 

	Qtp subdict=search auto=myqtp.qtc dbaudit=file

Is the 'set file' statement at the end of the qtp run or in the first
request only ?

Regards, Joe.


-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Lemin, Graeme
Sent: 01 April 2005 07:17
To: powerh-l@lists.sowder.com
Subject: Probs in 8.40D

	Hi Listers

	Our upgrade from 7.10.G1 to 8.40D has struck yet another problem.

	First off, the usual stuff:

We are currently upgrading from:


VMS 7.3-1 and OracleRDB 7.1-03

to

VMS 7.3-2 and OracleRDB 7.1-04

and from Powerhouse from 7.10.G1 to 8.40D.


We have experienced severe problems where Powerhouse is locking out other
processes.  Looking at the log file from two requests within a single QTP
program (with trace flags enabled) we find:

~T Transaction Parameter Block: (len=4)
0000 (00000) TPB$K_VERSION = 1 
0001 (00001) TPB$K_ISOLATION_LEVEL3 (serializable)
0002 (00002) TPB$K_READ (read only)
0003 (00003) TPB$K_WAIT
~T Start_transaction (1) on db: 3, db count=1
Get     Retrieval by index of relation RDB$RELATIONS
  Index name  RDB$REL_REL_NAME_NDX [1:1]         Direct lookup 
Sort 
Cross block of 2 entries 
  Cross block entry 1 
    Conjunct 
    Leaf#01 BgrOnly RDB$RELATION_FIELDS Card=9317
      BgrNdx1 RDB$RFR_REL_NAME_FLD_ID_NDX [1:1] Fan=8
  Cross block entry 2 
    Get     Retrieval by index of relation RDB$FIELDS
      Index name  RDB$FIELDS_NAME_NDX [1:1] Bool     Direct lookup 
Run:     PH_EXT_0

Request: GET_CURR_WORK_ORDERS

Executing request GET_CURR_WORK_ORDERS ...

~T Compile transaction (1) on db: 2
~T Transaction Parameter Block: (len=120)
0000 (00000) TPB$K_VERSION = 1 
0001 (00001) TPB$K_ISOLATION_LEVEL3 (serializable)
0002 (00002) TPB$K_WRITE (read write)
0003 (00003) TPB$K_WAIT
0004 (00004) TPB$K_LOCK_READ (reserving) "WIZ_SALES_AGENTS" TPB$K_SHARED
0017 (00023) TPB$K_LOCK_READ (reserving) "CTH_HP_DESCRIPTION" TPB$K_SHARED
002C (00044) TPB$K_LOCK_READ (reserving) "WIZ_WO_LINE_HISTORY" TPB$K_SHARED
0042 (00066) TPB$K_LOCK_READ (reserving) "CTH_WO_HISTORY" TPB$K_SHARED
0053 (00083) TPB$K_LOCK_READ (reserving) "WIZ_WO_LINE_ITEMS" TPB$K_SHARED
0067 (00103) TPB$K_LOCK_READ (reserving) "CTH_WORK_ORDER" TPB$K_SHARED
~T Start_transaction (1) on db: 2, db count=1

As mentioned, these passes are within the same QTP program.  The files are
opened as "OPEN 1 READ SHARE".

If we run the same code, in the same environment but using 7.10.G1, then the
TPB$K_WRITE parameter is set to READ ONLY in both cases.  Our DBAs have
confirmed that the "read write" is what is causing other transactions to be
locked out.

This has become a "show stopper" for us, to the point where our customer is
going to decide on Monday whether it's worth going ahead with the upgrade or
not.   

Has anyone seen anything like this before, or have any suggestions?

Thanks again.

regards

Graeme Lemin
Telstra Multimedia
Melbourne, Australia
+61 3 8695 7040
graeme.lemin@team.telstra.com




-- 
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.sowder.com
Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request@lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.