RE: sql identity column generate always (WHY HAVE TO RESET)

Again I'd try the RFE. You may have to agree that it may not be 'exact' due to point in time considerations, caching, etc.
But if you are in a time crunch you could try the MI list
Or you could try a series of DMPOBJ on the table before/after an insert and compare the differences.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Craig Richards
Sent: Friday, May 24, 2019 10:54 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: sql identity column generate always (WHY HAVE TO RESET)

what about my even better question Craig?
How to detect?

Hi Jay,

I spent quite a lot of time trying to figure out why I was getting duplicates when I first started using these.

Eventually I realised and proved the issue was CPYF.
In my particulary case, I'd create the file with an IDENTITY and do a load of testing in a DEV environment and when I was happy, move it up to TST.
If it was a file which required some static data - then I'd CPYF the records from my DEV environment up to TST.

Often I wouldn't see the problem at first because the new file was created and ready to start creating records with ID = 1 and from all of my testing in DEV, the early records had been deleted, so maybe the first ID value copied from DEV to TST was something like 12.
So My TST version would run fine and dandy until I got to the 12th record, which would fail due to a record CPYF'd from DEV already having that ID.
But the 13th might work because it happened that my testing had removed that value from DEV, maybe everything would look fine for a couple of inserts and then I'd hit another duplicate. Confusing at first.

Once I learned only to insert records into these tables with RLA in a program or SQL (omitting the ID column) I never had a problem.

With regard to your question though - sorry I haven't had occasion to figure out where the next value is stored.
I've kicked the next value on using ALTER TABLE T ALTER COLUMN ID RESTART with N etc but I'm sure you are aware of this.

Also I guess if you are using these you have come across
identity_val_Local() which you can use to determine the ID of the record your process just wrote.
But I couldn't immediately see another function that might retrieve the "next" ID value, although in practice by the time you retrieve that value it might be out of date.

I had a quick look in SYSCOLUMNS and the info doesn't seem to be there so I'm sorry I'm not sure how you would run a check.
I'd be interested to see if anyone knows where to get that info but I don't have time just at the moment to go digging.

regards,
Craig

On Fri, 24 May 2019 at 14:38, Jay Vaughn <jeffersonvaughn@xxxxxxxxx> wrote:

what about my even better question Craig?

How to detect?

On Fri, May 24, 2019 at 9:32 AM Craig Richards
<craig@xxxxxxxxxxxxxxxx>
wrote:

CPYF probably - it will keep ID from from_file and not increment ID
in to-file

On Fri, 24 May 2019 at 14:26, Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

id BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY
(START WITH 1 INCREMENT BY 1)
primary key(id)

We all know that sometimes the identity column gets "out of whack"
and

that

we have to reset it with the alter/restart...

My question is why does it get out of whack.
Even better question, how can we detect the presence of the out of
whackness before we are faced with a "attempt to write duplicate"

because

it was "out of whack"?
Is there a system table we can query to look at to detect these
time

bombs?

Abused google looking for an answer and everyone prides themselves
with

how

to restart it... and never is it explained how to detect them

beforehand.

TIA

jay
--
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@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com

--
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@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com

--
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@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
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@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com