Run the program in debug, add breakpoint where subfile is
being loaded.
When it breaks use DSPJOB and check the jobs library list
and the open files and the overrides.
Compare this on both systems
John
-----Original Message-----
From: CRPence [mailto:CRPbottle@xxxxxxxxx]
Sent: Thursday, June 06, 2013 11:11 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Brainstorming
On 05 Jun 2013 12:28, Thomas Garvey wrote:
We have a program that is apparently failing at a user
site, but not
on our test and development systems. The nature of the
failure is
that selected data does not appear as expected in a
subfile program.
To test it we had the object library and data library from
the user
system saved and sent to our test system. We restored the
objects and
tested the process here. It works just fine.
So, what could be different at the user site and our site
that would
change whether records are displayed in a subfile?
<<SNIP>>
Any other ideas that would make something work on one
system and not
another? Remember, both the program object and data files
libraries
from the user site were restored to the test system.
Thanks for any advice.
Check the history log from after the restore of the data
library, for "access path rebuilt" messages. Also check for
increased Access Path sharing on the restored copy as
compared to the test and dev systems.
An assumption by the code that a specific [un]shared
keyed AccPth is being used, could cause the code to fail
when the assumption fails due to the side effects of
save\restore for database file access paths.
Note: having properly requested the saving of access paths
would minimize [but not prevent] rebuilds, but would do
nothing to prevent sharing, because only an incompatible
definitional difference between sufficiently-like AccPths
will prevent the DB from effecting the sharing.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3184/6369 - Release
Date: 05/30/13 Internal Virus Database is out of date.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3184/6389 - Release
Date: 06/06/13
midrange.com
