Probs in 8.40D
Joe Boyle
atla38@dsl.pipex.com
Mon, 4 Apr 2005 16:18:15 +0100
one solution ( aside from re-activating 710G behaviour ) might be to enable
qtp syntax to autocommit reference-only tables, as is the case with quick.
Regards, Joe.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Joe Boyle
Sent: 04 April 2005 15:35
To: 'Deskin, Bob'; powerh-l@lists.sowder.com
Subject: RE: Probs in 8.40D
all fair comments of course, but if you are adding 'SET FILE xxx OPEN READ'
to the qtp, are you not telling qtp that creating a read only additional
transaction is desired in this case - and that you don't care about the
consequences of reference-only data being changed during the run/request.
To have to add 'commit at update' in order to release rows/locks is very
slow, and affects the consistency of the updateable rows as well as the
reference-only rows, and that is undesirable.
P.S. as always, I recognize that what anyone wants in a given scenario is
always highly subjective, but apparently 7.10.Gn did what 8.40.D now does
not do, so if its good enough for 7.10.Gn, why not 8.40.D also :)
Regards, Joe.
-----Original Message-----
From: Deskin, Bob [mailto:Bob.Deskin@Cognos.COM]
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.
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.