AW: Embedded SQL Ignoring OVRDBF

What's the override scope of your override command?
Default? Default is Activation Group. If you are dealing with different
activation groups the override is only valid for the appropriate activation
group.
Within an (program) the option *CALLLVL would be the best choice. With
*CALLLVL the override is valid for all sub-sequent call stack entries within
the call stack.
With override scope *JOB the override is valid for the whole job.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"


-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Sam_L
Gesendet: Thursday, 26. May 2011 02:00
An: midrange-l@xxxxxxxxxxxx
Betreff: Embedded SQL Ignoring OVRDBF

Has anyone experienced embedded SQL ignoring an OVRDBF and updating the
wrong file?

We have a CL program CLMAIN that contains conceptual code like this:

CPYF A_FILE to A_FILEX *REPLACE
OVRDBF A_FILE to A_FILEX
CALL RPG_A
CALL RPG_B
CALL RPG_C
Etc.
DLTOVR *ALL
RETURN

Program RPG_C is SQLRPGLE. It opens a cursor over A_FILE for UPDATE of
a couple of fields.

It iterates over the cursor conditionally doing ?Update A_FILE set field
= value WHERE CURRENT OF ??. This should update A_FILEX because of the
OVRDBF.

<<Occasionally>> an execution of program RPG_C updates A_FILE instead of
updating A_FILEX. I have determined this by analyzing the journal
records. So far I have failed to recreate the situation in a test
environment--A_FILEX gets updated as expected.

I?m clutching at straws here, wondering if the SQL runtime is
occasionally missing the OVRDBF.

I don?t see how the OVRDBF could be removed, except by the DLTOVR at the
end of the program. The programs in CLMAIN run in the default
activation group so the OVRDBF is scoped to the call level. Some of the
programs use SQL, often with a mix of native IO. Some call CL programs
that may do overrides, but those overrides would be at a different call
level than CLMAIN and I can?t see how they could effect it.

CLMAIN is invoked from an RPG III menu program, probably via QCMDEXC.
CLMAIN can be run again and again from the menu, or may be executed
interspersed with execution of other menu programs.

We are on V6R1, but not up to date on PTFs.

Sam