And awful practice to allow indexes, views, logical files, etc, in any
library other than the location of the dependent table. Particularly in a
developers library where that individual may think they are updating DEV or
QA versions when in actuality it's production that's getting hit.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Tim
Fathers
Sent: Wednesday, June 24, 2020 10:23 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: DEnglander@xxxxxxxxxxxxxxx
Subject: Re: Indexes not in a job's library list
Yes, this is normal, SQL will use any available index as far as I know.
Tim.
________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of
DEnglander--- via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>
Sent: 24 June 2020 17:01
To: midrange-l@xxxxxxxxxxxxxxxxxx <midrange-l@xxxxxxxxxxxxxxxxxx>
Cc: DEnglander@xxxxxxxxxxxxxxx <DEnglander@xxxxxxxxxxxxxxx>
Subject: Indexes not in a job's library list
I am using a V7R3 system.
I have a library that has a data file in it [DDS] and a SQL index over it in
that same library. That SQL index is also duplicated in another developer
library, so the DDS file has two SQL indexes over it, one in the developer's
library, and one in the library the data file is located in.
I call a program that has a SQL statement in it in a session that does not
have the developer's library name in the library list. When I entered
WRKACTJOB and took option 5 then 14 on that job, the list showed the program
had open the SQL index in the developer library, something I was surprised
to see.
I then deleted the file in the developer's library and called the program
again. The 5-14 then shows the program using the same index, but the one in
the library where the data file is located, which is correct.
Has anyone experienced this, where an SQLRPGLE program uses indexes that are
not in its library list? There is no hardcoding in the program source to go
to the developer's library.
Thank you,
Doug
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
