Probs in 8.40D
Lloyd, Gavin
gavin.lloyd@fmglobal.com
Mon, 4 Apr 2005 16:30:25 +0100
There are various permutations. The way I remember it (and this was
done 2 years ago) was that even a simple qtp with 'read only' on all
files still creates a read/write transaction. Also all our qtps which
had updates where we did not want the read only files locked we declared
'Set File xxx Open 1 Read' - i.e. create it's own transaction separate
from the update tables, but this also got created as read/write. It is
a change to the behaviour of qtp which totally blew our upgrade
prospects out of the water, which doesn't really matter because the
system has been on the retirement plan for 4 years now!!!!
Regards,
Gavin.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Deskin, Bob
Sent: 04 April 2005 13:47
To: Joe Boyle; powerh-l@lists.sowder.com
Subject: RE: Probs in 8.40D
Keep in mind that the OPEN READ|etc syntax was in QTP originally for
non-relational files and was adapted for relational. I forget why we did
that rather than add a transaction statement. However, just because one
table is opened for read doesn't mean that the entire transaction, which
may include other tables, should be read-only. the other option would be
to create an additional transaction, which may not be desirable.
Bob
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Joe Boyle
Sent: April 4, 2005 8:34 AM
To: powerh-l@lists.sowder.com
Subject: RE: Probs in 8.40D
I wonder what 'SET FILE xxx OPEN READ' was designed to do if not create
a read only transaction for the table; and presumably allow other
processes concurrent read/write access as with reference files in
screens.
I suppose it could be to block other writers while qtp is accessing rows
from the table; but I thought that was what the consistency Tx did
anyway, and so I would expect the 'set file ... read' override to allow
others read/write access.
Regards, Joe.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Lloyd, Gavin
Sent: 04 April 2005 10:26
To: Lemin, Graeme; powerh-l@lists.sowder.com
Subject: RE: Probs in 8.40D
We are running OpenVMS V7.1-2, Oracle Rdb V7.0-65, Powerhouse 7.10.G4.
We tested 8.30D and experienced the following problems:
Case No: 3122113
Date Logged: 24-Apr-2003
Bug No.: 406680
Fixed: Yes
Fixed Version: 8.30D3
Issue: Problem locating database when using searchlist logicals
Case No: 3123401
Date Logged: 02-May-2003
Bug No.: 404930
Fixed: No
Issue: 'SET FILE xxx OPEN READ' does not create a read only transaction
Case No: 3124064
Date Logged: 07-May-2003
Fixed: Yes
Issue: Retrieval on SMALLINT columns combined with CHARACTER columns
does not work
Solution: In the PHD File screen change the type for the databases from
RDB/VMS to RDB
Case No: 3126513
Date Logged: 22-May-2003
Bug No.: 406779
Fixed: Yes
Fixed Version: 8.30D3
Issue: '%RDB-E-UNRES_REL' error
Case No: 1111339
Date Logged: 30-May-2003
Bug No.: 407579
Fixed: Yes
Issue: 'COMMIT AT RUN' is commiting transactions at each request
Solution: In the PHD File screen change the type for the databases from
RDB/VMS to RDB
As you can see 4 of the 5 were resolved (the PHD change needs a full
recompile to take effect), but Case 3123401 was deemed a functionality
change and not 'changed' so you will have to discuss with Cognos.
Regards,
Gavin.
-----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.
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.
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 promptly by e-mail that you have done so. Thank you.