dbschema : 100 - ISAM error: duplicate value for
A user on IDS 9.40/Solaris hit "100 - ISAM error: duplicate value for a record with unique key" while running/applying dbschema -ss output, failing at the CREATE INDEX statements. Art Kagel explained it as name clashes between explicitly named indexes and system-generated names for unnamed indexes/constraints (generated names derive from tabids, which change after non-in-place ALTERs), and recommended editing the SQL manually or using his myschema utility (utils2_ak), which names all implicit objects. A later poster noted the same error when using an old 7.22 dbschema against an 11.10 database, fixed by using the version-matched dbschema. No confirmation from the original poster is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi Folks,
running IDS 9.40 on Solaris.
During dbschema, th ejob was interrupted with the message above.
Any idea how I can easily determine the table with the problem ?
Here are the last lines of the output of dbschema :
{ TABLE "cti".acth row size = 56 number of columns = 6 index size = 9 }
create table "cti".acth
(
nmed integer not null ,
nagr decimal(11),
nom char(25),
pren char(15),
statut_envoi char(1),
type_envoi char(4)
) in chrvs1 extent size 500 next size 100 lock mode page;
revoke all on "cti".acth from "public";
100 - ISAM error: duplicate value for a record with unique key.
Thanks for your help.
Jacques Lapeire
I'm going to guess that you are using the output of dbschema -ss to recreate
an existing database on another server or a differently named database with
the same set of tables. If that's so, the problem is that the script
contains a combination of named and unnamed indexes and constraints and some
of the named objects are clashing with unnamed objects for which the engine
has generated default names. IDS is generating different names for the
implicitly named objects than it did in the source database and these names
are clashing with some of the explicit object names.
The most likely culprit is an index or constraint on this particular table,
acth, but that depends on how you were running the dbaccess session and how
you determined where the problem was encountered. It could be a table later
in the file.
One solution is to use my dbschema replacement utility, myschema, to get the
schema from the source database. Myschema was specifically created to avoid
these kinds of problems. It creates explicit names for all implicitly named
objects in the output schema. The explicit names are based on the existing
implicit names in the source server so there can be no clashes in the target
server when you execute the DDL script.
Myschema is contained in the package utils2_ak which you can download from
the IIUG Software Repository (www.iiug.org/software) or from the Oninit web
site (www.oninit.com/utils).
Art
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
On Tue, Dec 15, 2009 at 10:22 AM, JACQUES LAPEIRE <
jacques.lapeire@ts.fujitsu.com> wrote:
> Hi Folks,
>
> running IDS 9.40 on Solaris.
>
> During dbschema, th ejob was interrupted with the message above.
>
> Any idea how I can easily determine the table with the problem ?
>
> Here are the last lines of the output of dbschema :
>
> { TABLE "cti".acth row size = 56 number of columns = 6 index size = 9 }
> create table "cti".acth
> (
>
> nmed integer not null ,
>
> nagr decimal(11),
>
> nom char(25),
>
> pren char(15),
>
> statut_envoi char(1),
>
> type_envoi char(4)
> ) in chrvs1 extent size 500 next size 100 lock mode page;
> revoke all on "cti".acth from "public";>
> 100 - ISAM error: duplicate value for a record with unique key.
>
> Thanks for your help.
>
> Jacques Lapeire
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--000e0cdfd704f0a5ea047ac7a8a7
Hi Art,
yes , you are right I'm using the -ss option,
in fact I'm using : dbschema -d isa -ss > isa.sql
I started it once more and now it's going further, the error appears when
generating the "create index"-statements.
create unique index "root".iprw1 on "root".iprw (nina,tarif,ddeb
desc) using btree in par1 ;
create index "cti".acth1 on "cti".acth (nmed) using btree in
chrvs1 ;
100 - ISAM error: duplicate value for a record with unique key.
Could it be because I run the dbschema while everyone is still working (~ 150
sessions active) ?
I've run this several times before without any problems, during migrations,
always in addition
to the dbexport, but then of course no one is connected.
Thx,
Jacques
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel
Sent: Tuesday, December 15, 2009 6:24 PM
To: ids@iiug.org
Subject: Re: dbschema : 100 - ISAM error: duplicate val.... [18395]
I'm going to guess that you are using the output of dbschema -ss to recreate
an existing database on another server or a differently named database with
the same set of tables. If that's so, the problem is that the script
contains a combination of named and unnamed indexes and constraints and some
of the named objects are clashing with unnamed objects for which the engine
has generated default names. IDS is generating different names for the
implicitly named objects than it did in the source database and these names
are clashing with some of the explicit object names.
The most likely culprit is an index or constraint on this particular table,
acth, but that depends on how you were running the dbaccess session and how
you determined where the problem was encountered. It could be a table later
in the file.
One solution is to use my dbschema replacement utility, myschema, to get the
schema from the source database. Myschema was specifically created to avoid
these kinds of problems. It creates explicit names for all implicitly named
objects in the output schema. The explicit names are based on the existing
implicit names in the source server so there can be no clashes in the target
server when you execute the DDL script.
Myschema is contained in the package utils2_ak which you can download from
the IIUG Software Repository (www.iiug.org/software) or from the Oninit web
site (www.oninit.com/utils).
Art
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
On Tue, Dec 15, 2009 at 10:22 AM, JACQUES LAPEIRE <
jacques.lapeire@ts.fujitsu.com> wrote:
> Hi Folks,
>
> running IDS 9.40 on Solaris.
>
> During dbschema, th ejob was interrupted with the message above.
>
> Any idea how I can easily determine the table with the problem ?
>
> Here are the last lines of the output of dbschema :
>
> { TABLE "cti".acth row size = 56 number of columns = 6 index size = 9 }
> create table "cti".acth
> (
>
> nmed integer not null ,
>
> nagr decimal(11),
>
> nom char(25),
>
> pren char(15),
>
> statut_envoi char(1),
>
> type_envoi char(4)
> ) in chrvs1 extent size 500 next size 100 lock mode page;
> revoke all on "cti".acth from "public";>
> 100 - ISAM error: duplicate value for a record with unique key.
>
> Thanks for your help.
>
> Jacques Lapeire
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--000e0cdfd704f0a5ea047ac7a8a7
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
I'm assuming that these tables don't already exist at the time you are
running the schema create, so those indexes should not exist either. More
likely it is indexes created by a constraint that is not supported by an
already existing named index. That's one of the enhancements that myschema
gives you over dbschema. It forces the creation of a named index for every
constraint that needs one if it doesn't already exist. Why is this a
problem recreating a database when it wasn't a problem in the original?
Well, it has to do with the order of the tabids. You likely have altered
some of the tables over time and some of those alters were not in-place so
the tables' tabids changed. The engine uses the tabid to name unnamed
objects. However, the old names of the these objects belonging to
renumbered tables still use the older tabid and that's clashing with the
newly created tables' objects. It's weird, I know. Anyway, you can either
edit the SQL manually, or use myschema to avoid the problem.
If you want, send me the SQL file privately and I'll try to spot the problem
DDL, but it's easier to just get, compile, install, and use myschema.
Really.
Art
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do
those opinions reflect those of other individuals affiliated with any entity
with which I am affiliated nor those of the entities themselves.
On Thu, Dec 17, 2009 at 6:05 AM, Lapeire, Jacques <
jacques.lapeire@ts.fujitsu.com> wrote:
> Hi Art,
>
> yes , you are right I'm using the -ss option,
> in fact I'm using : dbschema -d isa -ss > isa.sql
>
> I started it once more and now it's going further, the error appears when
> generating the "create index"-statements.
>
> create unique index "root".iprw1 on "root".iprw (nina,tarif,ddeb
>
> desc) using btree in par1 ;
> create index "cti".acth1 on "cti".acth (nmed) using btree in
>
> chrvs1 ;
> 100 - ISAM error: duplicate value for a record with unique key.
>
> Could it be because I run the dbschema while everyone is still working (~
> 150
> sessions active) ?
>
> I've run this several times before without any problems, during migrations,
> always in addition
> to the dbexport, but then of course no one is connected.
>
> Thx,
>
> Jacques
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
> Kagel
> Sent: Tuesday, December 15, 2009 6:24 PM
> To: ids@iiug.org
> Subject: Re: dbschema : 100 - ISAM error: duplicate val.... [18395]
>
> I'm going to guess that you are using the output of dbschema -ss to
> recreate
> an existing database on another server or a differently named database with
> the same set of tables. If that's so, the problem is that the script
> contains a combination of named and unnamed indexes and constraints and
> some
> of the named objects are clashing with unnamed objects for which the engine
> has generated default names. IDS is generating different names for the
> implicitly named objects than it did in the source database and these names
> are clashing with some of the explicit object names.
>
> The most likely culprit is an index or constraint on this particular table,
> acth, but that depends on how you were running the dbaccess session and how
> you determined where the problem was encountered. It could be a table later
> in the file.
>
> One solution is to use my dbschema replacement utility, myschema, to get
> the
> schema from the source database. Myschema was specifically created to avoid
> these kinds of problems. It creates explicit names for all implicitly named
> objects in the output schema. The explicit names are based on the existing
> implicit names in the source server so there can be no clashes in the
> target
> server when you execute the DDL script.
>
> Myschema is contained in the package utils2_ak which you can download from
> the IIUG Software Repository (www.iiug.org/software) or from the Oninit
> web
> site (www.oninit.com/utils).
>
> Art
>
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> See you at the 2010 IIUG Informix Conference
> April 25-28, 2010
> Overland Park (Kansas City), KS
> www.iiug.org/conf
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and
> do not reflect on my employer, Oninit, the IIUG, nor any other organization
> with which I am associated either explicitly or implicitly. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity
> with which I am affiliated nor those of the entities themselves.
>
> On Tue, Dec 15, 2009 at 10:22 AM, JACQUES LAPEIRE <
> jacques.lapeire@ts.fujitsu.com> wrote:
>
> > Hi Folks,
> >
> > running IDS 9.40 on Solaris.
> >
> > During dbschema, th ejob was interrupted with the message above.
> >
> > Any idea how I can easily determine the table with the problem ?
> >
> > Here are the last lines of the output of dbschema :
> >
> > { TABLE "cti".acth row size = 56 number of columns = 6 index size = 9 }
> > create table "cti".acth
> > (
> >
> > nmed integer not null ,
> >
> > nagr decimal(11),
> >
> > nom char(25),
> >
> > pren char(15),
> >
> > statut_envoi char(1),
> >
> > type_envoi char(4)
> > ) in chrvs1 extent size 500 next size 100 lock mode page;
> > revoke all on "cti".acth from "public";> >
> > 100 - ISAM error: duplicate value for a record with unique key.
> >
> > Thanks for your help.
> >
> > Jacques Lapeire
> >
> >
> >
> >
>
>
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --000e0cdfd704f0a5ea047ac7a8a7
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001517477f1e7c8e07047aeb4187
I get this error using older dbschema 7.22 UC2.
Against my newer 11.10 database.
But the dbschema distributed with 11.10 works fine.
OK, that raises the obvious question: Why are you trying to use the REALLY
ANCIENT v7.22 dbschema utility with 11.10 when you have a perfectly fine
working dbschema that was delivered with your 11.10 engine that you have
verified works OK?
The reason you are having problems is that there have been myriad changes to
the system catalog since IDS 7.22 among which was the expansion of all
object names from a maximum of 18 characters in 7.xx through 9.20 to 128
characters in versions 9.21 and later including the 11.xx series. Likewise
user names were expanded from 8 characters to 32 characters. Some tables
were replaced by VIEWs into expanded replacement tables and many other
changes including changes to the column lists in other catalog tables.
The specific error you have encountered indicates that dbschema ran into a
UNIQUE or PRIMARY KEY constraint or unique index where it didn't expect to
find one. Likely that is due to a change to the database catalog's schema
since 7.22 was current.
If you need dbschema's capability on a system that does not have an 11.10 or
later engine, download my package utils2_ak from the IIUG Software
Repository (www.iiug.org/software) and build it. That package contains my
dbschema replacement utility, myschema, which is compatible with all current
and past releases of IDS and Online - though it has lots of added features
that dbschema does not support it does support all dbschema options except
-hd (data distribution display). All you need to build myschema is an ANSI
C compiler and the CSDK v3.50 or later (an ealier version is included in the
11.10 install so you may have to install the later release).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Wed, Jan 13, 2010 at 11:01 AM, BRUCE ANDERSON
<bruce@the-connection.com>wrote:
> I get this error using older dbschema 7.22 UC2.
> Against my newer 11.10 database.
> But the dbschema distributed with 11.10 works fine.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001517402ba8b352ed047d0e41fb