Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <26331544.1201090234256.JavaMail.jira@brutus>
Date: Wed, 23 Jan 2008 04:10:34 -0800 (PST)
From: "Dyre Tjeldvoll (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3343) Subsequent calls to
 PreparedStatement cause SQLIntegrityConstraintViolationException on column
 that is  "Generated always"
In-Reply-To: <33509235.1201058074124.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561647#action_12561647 ] 

Dyre Tjeldvoll commented on DERBY-3343:
---------------------------------------

I agree, but I'm also worried about what happens when some of the other predicates are true. Will that ever happen, and could it cause problems? We should probably have some more test cases for default values that change between executions, but I don't know all the different ways in which this could happen.


> Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is  "Generated always"
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3343
>                 URL: https://issues.apache.org/jira/browse/DERBY-3343
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.2.1
>         Environment: gentoo linux amd64
>            Reporter: William Becker
>            Assignee: Dyre Tjeldvoll
>         Attachments: d3343.diff
>
>
> The following series of statements fails:
> j> connect 'jdbc:derby:test;create=true';
> ij> create table t (id int primary key generated always as identity);
> 0 rows inserted/updated/deleted
> ij> prepare p as 'insert into t(id) values (default)';
> ij> execute p;
> 1 row inserted/updated/deleted
> ij> execute p;
> ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL080123140906700' defined on 'T'.
> There is a more detailed discussion about it here: http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.