Re: Identity Columns

Thanks Justin,

I read your RFE and previous discussion. Although it doesn't really shed
much light on what is happening in my case, it does show that there are
examples of anomalous behaviour out there I guess.

For me, this is a new(ish) file with only a handful of records on it.

My impression, based on not very much, was that somehow the "next ID" had
been cached by the database manager from when I ran the program the first
time, and then when I switched environments and wrote to the same file (
but in a different library ) the database manager gave me it's cached ID
which happened to be an existing ID in my "new" environment.

I'm not saying that there is any evidence to support this idea - All I know
is that somewhere in the mix of my program, the database manager and my
changing library lists, something has gotten out of kilter.

One thing I did notice that I mentioned before is I can see that ID's are
skipped. I guess this could be caused by me creating / deleting / creating
records causing a gap in the IDs but I'm also not sure if it has anything
to do with ID caching ( which I don't specify in my DDL. I think the
default is not to cache. )

Anyway, I'm going to leave things for now and see if I can recreate the
problem because for now it seems to have temporarily disappeared.
If it happens again I'll try to determine a bit more clearly what is going
on and then maybe switch to SQL for the insert, specifying DEFAULT for the
ID column or maybe even investigate Datastructure I/O and see if that makes
any difference.

thanks as always,
best regards,
Craig

On 14 June 2018 at 18:23, Craig Richards <craig@xxxxxxxxxxxxxxxx> wrote:

Hi Justin,

Thanks for your reply.
Hmm that's kind of concerning.

My issue so far has always manifested itself on a WRITE.
But it happens that I've always ended up in a WRITE situation from my
"work with" program by copying another record.

That said, in the program the file is qualified and the qualified version
of the ID column does not appear anywhere in the source.

I'll have a play and see if come up with anything based on the idea that a
previous update might have corrupted things.

Because despite all of this talk about environments and activation groups
and closing files and cursors ( which I think I have a pretty good handle
on ) that is all irrelevant if the RLA is not supposed to have any impact
on an ID GENERATED ALWAYS column...

best regards,
Craig

On 14 June 2018 at 18:14, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

GENERATED ALWAYS should, but does not ignore the value from an RLA UPDATE.



-----Original Message-----
From: Charles Wilt [mailto:charles.wilt@xxxxxxxxx]
Sent: Thursday, June 14, 2018 8:43 AM
To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Subject: Re: Identity Columns

GENERATED ALWAYS should ignore the what RPG passes in...

GENERATED BY DEFAULT would cause this problem...

Another possible source...do you have an SQL process that does an INSERT
with the "OVERRIDING SYSTEM VALUE" clause?

Charles



--
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: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD