ch
> > choice, because of the libraries you use (in particular JDBC, but you could
> > find many other examples in Java libs).
> >
> > Just my 2c
> >
> > Cheers
> >
> > Jean-Francois
> >
> > -Original Message-
> > From:
]
> Sent: Thursday, February 24, 2005 11:08 AM
> To: ibatis-user-java@incubator.apache.org
> Subject: Re: Duplicate Key in Db
>
> To be honest... that sounds like a bad decision. Using database error
> codes to determine application flow is very subjective and dangerous.
> I c
TED]
Sent: Thursday, February 24, 2005 11:08 AM
To: ibatis-user-java@incubator.apache.org
Subject: Re: Duplicate Key in Db
To be honest... that sounds like a bad decision. Using database error
codes to determine application flow is very subjective and dangerous.
I could see passing a human readable error
ption. It should hold a vendor
> > specific code that identifies the type of database error.
> >
> > - Original Message -
> > From: "Brice Ruth" <[EMAIL PROTECTED]>
> > To: ibatis-user-java@incubator.apache.org, "Tim Christopher"
SQLException?
>
> -Original Message-
> From: Tim Christopher [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 23, 2005 11:06 AM
> To: ibatis-user-java@incubator.apache.org
> Subject: Re: Duplicate Key in Db
>
> Sorry, I should have mentioned that I was talking about an ins
You are simply performing error interpreatation for user consumption.
So, no matter what SQLException gets thrown it will simply display an
error to the user. However, i would not recommend that you get into
the practice of deciding how to proceed based upon the type of
SQLException that is being t
My probably goes a little against the grain of what you are saying,
though I've only just read your comments...
What I've done is to extend the framework to allow iBATIS to return an
int for insertions calls, then created a constants file (as a HashMap)
to turn returned values into entries from th
rry Meadors [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 24, 2005 4:02 AM
> To: ibatis-user-java@incubator.apache.org
> Subject: Re: Duplicate Key in Db
>
> Man guys, this is going down a really ugly path.
>
> What happens when you get a new driver, and the message
ption. It should hold a vendor
> > specific code that identifies the type of database error.
> >
> > - Original Message -
> > From: "Brice Ruth" <[EMAIL PROTECTED]>
> > To: ibatis-user-java@incubator.apache.org, "Tim Christopher"
Meadors [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 24, 2005 4:02 AM
To: ibatis-user-java@incubator.apache.org
Subject: Re: Duplicate Key in Db
Man guys, this is going down a really ugly path.
What happens when you get a new driver, and the message changes from
"Invalid key" to &qu
; specific code that identifies the type of database error.
>
> - Original Message -
> From: "Brice Ruth" <[EMAIL PROTECTED]>
> To: ibatis-user-java@incubator.apache.org, "Tim Christopher" <[EMAIL
> PROTECTED]>
> Subject: Re: Duplicate Key
ibatis-user-java@incubator.apache.org, "Tim Christopher" <[EMAIL PROTECTED]>
Subject: Re: Duplicate Key in Db
Date: Wed, 23 Feb 2005 14:32:25 -0600
>
> I think you need to catch a DaoException, and check its cause. If its
> cause is a NestedSqlException, you'll need to interrogate
I think you need to catch a DaoException, and check its cause. If its
cause is a NestedSqlException, you'll need to interrogate that to
determine what the "real" cause was. In your case, it appears a
generic exception is thrown by the JDBC driver
(com.borland.datastore.driver.SqlState), with a "Run
>> You can do that now. Maybe I'm missing something?
>> The Ibatis insert() statement throws a SQLException.. ..
Below is the first part of stack dump that is triggers by the failed
insertion, so should I be catching a DaoException or
NestedSQLException?... Or is there anything else I can do?
>
Have you considered a stored procedure for this?
If the rules surrounding the data are as complex and fluid as they
sound, that may be the easiest way to centralize the managment of
them.
Larry
On Wed, 23 Feb 2005 18:54:02 +, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> So what happens if y
PROTECTED]
Sent: Wednesday, February 23, 2005 1:54 PM
To: ibatis-user-java@incubator.apache.org
Subject: Re: Duplicate Key in Db
So what happens if you have a SQL statement that inserts data into
serveral tables. Every change to the database would require you to
reevaluate what checks (select statem
So what happens if you have a SQL statement that inserts data into
serveral tables. Every change to the database would require you to
reevaluate what checks (select statements) need to be done to ensure a
situtation where it is possible for duplicate primary keys to occur in
each table. I do not
There is no way a framework would be able to accomplish that apart
from exactly what you stated. You should assure the verasity of the
object you want to insert before you attempt to insert it. That will
always happen against the databsae even if you created a memory
resident object identity layer.
I'll get my coat...
:-[
"The module code is a primary key and must be a unique value, though
it must match with a value stored in another system so can not be an
auto-increment value."
I don't think his situation would allow for that.
Brandon
I'd want to design it so that the database assigns th
"The module code is a primary key and must be a unique value, though
it must match with a value stored in another system so can not be an
auto-increment value."
I don't think his situation would allow for that.
Brandon
> I'd want to design it so that the database assigns the primary keys.
> It's
Tim,
I'd want to design it so that the database assigns the primary keys.
It's the best way to do it IMHO. Any object to be persisted is checked
for a primary key. If it's null, you do an insert; if it's not null,
you want an update. The database assigns primary keys and can use a
sequence
Can you perform the insert, and capture the error that comes back on the
SQLException?
-Original Message-
From: Tim Christopher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 11:06 AM
To: ibatis-user-java@incubator.apache.org
Subject: Re: Duplicate Key in Db
Sorry, I
Sorry, I should have mentioned that I was talking about an
insertion... Currently it is possible for a user to create a new
Module by specifying a module code, name, etc.. The module code is a
primary key and must be a unique value, though it must match with a
value stored in another system so ca
you should not specify your primary key in the update values of your
update statement. It should be part of your where criteria.
BAD:
UPDATE SOMETABLE
(somePrimaryKey,columnA,columnB,columnC)
VALUES(#somePrimaryKey#,#'valueA#,#valueB#,#valueC#)
WHERE somePrimaryKey = 1
GOOD:
UPDATE SOMETABLE
(c
24 matches
Mail list logo
