Re: Journal not showing update - DB won't update if nothing has changed?

Thank you Chuck!

That explains why I don't see the journal entries...

Your info makes perfect sense; and as I thought about it, I knew the DB at
least doesn't discard an update even if the fields don't change as I once
re-wrote a a process that used SQL do to a "dummy" update just so the
triggers would fire.

Of course, the philosophical side of me wonders...if there's no evidence an
update occurred...did it really occur? :)

Charles





On Thu, Mar 5, 2015 at 2:52 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 05-Mar-2015 10:06 -0600, Charles Wilt wrote:

Been looking into a issue and thought I had a handle on it.

Till I realized for certain records, I don't see an update entry in
the journal as I expected.

Back to the code...after spending a an hour or so looking. I really
can't see how the UPDATE wouldn't have have been hit.

Then it hits me, for a few records, none of the values in the fields
of the file would have actually changed between READ and UPDATE.

IIRC, RPG by design won't actually do an update unless the buffer's
changed.

On 05-Mar-2015 11:15 -0600, Charles Wilt wrote:

...I realized it probably should have been "RPG (or the DB)"...

In other words:
read myfile;
wFld1 = fFld1;
wFld2 = fFld2;
fFld1 = wFld1;
fFld2 = wFld2;
update myfileR;

Wouldn't actually update the record in myfile.

Can anyone confirm that I'm not misremembering?

None of the HLL [e.g. RPG] run-time, the DM, nor even the OS DB could
appropriately dismiss an UPDATE operation that was coded in the HLL, based
solely on an equivalence determined between the /buffer/ before the update
and the /buffer/ after the changes applied to the buffer. While the
programmer has the option of coding a bypass of the UPDATE within their
program, the onus is on the programmer to decide whether that [in]action is
proper, in accordance with the definitions of their application and
database; notably the business rules, which esp. if defined in the
database, may depend on the program *not* coding to avoid\omit the
presumed-redundant request.

FWiW the interface to the UPDATE, via the DM, does not provide any
storage [to the HLL] for both a pre-update copy of the record and the
actual record within the provide buffer-storage. There is only one copy of
the record that is made available via the buffer provided by the DM. The
changes to the /record/ in the HLL are applied directly to that buffer, and
then the UPDATE operation uses the data in that buffer to pass down to the
database.

Any interface from the HLL down to the DB that might choose to make a
pre-update copy of the record in order to attempt such a comparison and
avoid the UPDATE if equivalent, would be a flawed interface. That is
because the DataBase is the arbiter of the I\O. Interfaces above the DB
would not easily be able to predict that the effect from the UPDATE without
any /perceived/ data changes, might actually effect physical data changes,
irrespective their [possibly false] conclusion such a request would be
redundant. Again, the programmer\application could /know/ that coding the
bypass was acceptable, but the HLL itself must not presume the operation
can be bypassed solely due to apparent redundancy.

At least some of the following may result in an effect whereby physical
changes will be visible, despite apparent equivalence of pre-update and
post-update buffers as compared immediately prior to the UPDATE; the last
item is presumably a means to ensure that even for an apparent-equivalence
scenario, the UPDATE should effect a change to the physical data:
• [instead of] triggers
• with check option
• fieldproc
• row change timestamp

The lack of a journal entry being deposited for an UPDATE [that was
passed from the HLL via the DM to the OS DB and then down to the LIC DB] is
the domain of the LIC Journal feature:

<http://www.ibm.com/support/knowledgecenter/api/content/
ssw_ibm_i_71/rzaki/rzakihowwrks.htm>
_How journal management works_
"...
_Journal receivers_

The system writes entries to an object called a journal receiver.

...

... If the updated physical file image after the update is the same as
the image before the update, and if the file has no variable length fields,
then journal entries are not deposited for that update. If the updated data
area image after the update is the same as the image before the update,
then journal entries are not deposited for that update. If the attribute
that was requested to be changed was already that value, then journal
entries are not deposited for that change.
..."

--
Regards, Chuck

--
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.