Re: SQLSTATE 23513, get constraint name?

Something to consider..

Instead of just CHK_TESTDIAG as a name

1) You can use long names. CHECK_TEST_DIAGNOSTIC is perfectly valid and
makes more sense
2) Even better, CHECK_TEST_DIAGNOSTIC_ERR0100 where you postfix a message
ID to the constraint

Now you could extract the MSGID, and then retrieve more details about the
problem..

Stolen from here:
http://www.itjungle.com/fhg/fhg021710-story01.html

Charles


On Mon, Jan 4, 2016 at 2:50 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Somehow I missed your prior post. Your sample is perfect!

Thanks




-----Original Message-----
From: Luis Rodriguez [mailto:luisro58@xxxxxxxxx]
Sent: Wednesday, December 30, 2015 10:46 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: SQLSTATE 23513, get constraint name?

Justin,

I don't know if you got my prior post about using GET_DIAGNOSTICS...

Suppose you create the following table:




*Create table testdiag ( f1 char not null with default '', constraint
chk_testdiag check (f1 <> 'x') ) *
You can use the GET DIAGNOSTICS sentence into a program like this:










* HDebug(*yes) DC_Name S 128 Varying
/free exec sql insert into Testdiag (F1) values('X') ;
exec sql get diagnostics condition 1 :C_Name = Constraint_Name
; dump ;
return;
*

In this case, C_Name would return 'CHK_TESTDIAG'

Is this what you are asking about?

Regards,


Luis Rodriguez

--


On Wed, Dec 30, 2015 at 11:28 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
wrote:

The corresponding SQLCODE message (SQL0545) gives the same text as
what GET DIAGNOSTICS EXCEPTION gave me. The message text in the
joblog is also the same. The Cause listed in the joglog does include
the constraint name. Any painless way to get that programmatically?



-----Original Message-----
From: Vernon Hamberg [mailto:vhamberg@xxxxxxxxxxxxxxx]
Sent: Wednesday, December 30, 2015 8:08 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: SQLSTATE 23513, get constraint name?

Take a look at the job log - there are often more messages that were
logged before the one you are seeing. And getting an SQLSTATE, there
will definitely be some kind of messages out there

Also check SQLCODE for a value - that value is often made part of a
message ID - for example, if SQLCODE is 367, say, the message ID will
be SQL0367.

But that message, if any, will be part of the job log.

This is a WAG, but based on seeing lots of messages logged in other
error conditions for SQL.

HTH
Vern

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

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