×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Thanks to all who replied. The PRTSQLINF helped. The basic business problem is that the sort sequence *LANGIDSHR is specified somewhere, but not explicitly by us. This has performance implications of the negative kind, which business users do not like.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Wednesday, June 19, 2013 9:49 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: SQL options precedence for SQLRPGLE
On 6/19/2013 12:01 PM, Josh Diggs wrote:
I am trying to determine If there is any interaction between a third party application and my program with regards to the SQL options.
As programmers, we tend to see problems as technical issues but very often describing the actual business problem (for example, '3rd party program complains about journaling') will trigger more replies than the more generic description of the hypothetical problem space.
My understanding is that these options can be set with a QAQQINI entry, at compile time via the command, or at compile time via a SET OPTION statement in source.
What makes sense to me is that QAQQINI would provide defaults, the compile command could override those defaults, and the SET OPTION would be the final word. Is that correct?
I can't think of many QAQQINI options that can be overridden by SET OPTION or compile time settings and I'm on 7.1. So the only real hierarchy is between the compiler defaults and SET OPTION.
Also, can anyone describe how I might see the SQL options that are active during a debug session, and the SQL options that were specified at compile time (something along the lines of DSPPGM)?
DSPPGM doesn't store any compile time options, not even for OPM RPG programs. For instance you can't tell if the program was compiled with IGNDECERR or FIXDECERR or not.
I don't think any of the debuggers have a special command to expose SQL information; PRTSQLINF is probably the only thing available.
--buck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.