Re: (SQL) Identity Crisis -- MIDRANGE-L

Subject: Re: (SQL) Identity Crisis
From: CRPence <CRPbottle@xxxxxxxxx>
Date: Fri, 05 Apr 2013 12:41:35 -0700
List-archive: <http://archive.midrange.com/midrange-l>
List-help: <mailto:midrange-l-request@midrange.com?subject=help>
List-id: Midrange Systems Technical Discussion <midrange-l.midrange.com>
List-post: <mailto:midrange-l@midrange.com>
List-subscribe: <http://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@midrange.com?subject=subscribe>
List-unsubscribe: <http://lists.midrange.com/mailman/listinfo/midrange-l>, <mailto:midrange-l-request@midrange.com?subject=unsubscribe>

On 05 Apr 2013 10:49, Charles Wilt wrote:

Also not that the GENERATED ALWAYS might be problematic when
recreating the table...as I believe unless you've never deleted
anything from the table and the system reads the original data in
identity order, you'll find that your identity columns get new
values when the data is copied back.

That really depends on how the /copy/ is implemented. The OP never stated explicitly what implemented their "copied" activity. IIRC the CPYF always has the effect of having specified the OVERRIDING SYSTEM VALUE clause on an INSERT; for which, if there is no column matching the identity in the target, the value is GENERATED, instead of the error SQL0109 being issued like if the request had been actual SQL. So very likely, the OP used CPYF to effect the copy activity.?

As an Amazon Associate we earn from qualifying purchases.

Follow-Ups:

Re: (SQL) Identity Crisis , Charles Wilt

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.