Toad World® Forums

Schema Compare Issue [6 Attachments]


#1

[ Attachment(s) from yroy@cmhc-schl.gc.ca included below]

Good day,

Using the latest beta drop with DB2 LUW 9.1fp5 on windows 32 bits, I have done
some testing of the schema compare feature and I have found the following
opportunities
Using “Temporary Tables”
DDL generated is fine but data in target table not preserve
Using “Commands/utilities” with or without “Load utility when applicable”
I get the following error:

    because the DDL generated contains a drop of the index supporting the
    primary constraint

Here is the supporting files:

Let me know if you need more info

Thanks

Yvan

att1.dat (25.5 KB)


#2

Hi Yvan,

There was a recent fix for the SQL0669N problem you saw. Please try the latest
beta and see if it resolves the problem.

I opened CR 70,718 to track the issue of Schema Compare Synchronize not
preserving target data.

Thanks,

Adam
image001.gif (25.5 KB)


#3

[ Attachment(s) from yroy@cmhc-schl.gc.ca included below]

Hi Adam,

The latest drop solved the SQL0669N issue but unfortunately introduced a new one
as well. For Naming Standard reason, we want to explicitly name our primary
index ( create table, create index and alter table to add primary key). The
Schema compare does not recreate our named primary key index so subsequent
compare still detect a missing index that we can’t create since DB2 implicitly
created an index to support the primary key constraint.

Let me know if need more info

Thanks

Yvan

First Compare generates:
and if we execute the DDL generated by the second compare here is what i get:

Adam Ririe
Sent by:

28/01/2010 11:05 AM

Please respond to
toaddb2beta@ yahoogroups. com

To

“toaddb2beta@ yahoogroups. com”

cc

Subject

RE: [toaddb2beta] Schema Compare Issue

Classification

Hi Yvan,

There was a recent fix for the SQL0669N problem you saw. Please try the latest
beta and see if it resolves the problem.

I opened CR 70,718 to track the issue of Schema Compare Synchronize not
preserving target data.

Thanks,

Adam
att1.dat (36.4 KB)


#4

[ Attachment(s) from yroy@cmhc-schl.gc.ca included below]

Hi Adam,

The latest drop solved the SQL0669N issue but unfortunately introduced a new one
as well. For Naming Standard reason, we want to explicitly name our primary
index ( create table, create index and alter table to add primary key). The
Schema compare does not recreate our named primary key index so subsequent
compare still detect a missing index that we can’t create since DB2 implicitly
created an index to support the primary key constraint.

Let me know if need more info

Thanks

Yvan

First Compare generates:
and if we execute the DDL generated by the second compare here is what i get:

Adam Ririe
Sent by:

28/01/2010 11:05 AM

Please respond to
toaddb2beta@ yahoogroups. com

To

“toaddb2beta@ yahoogroups. com”

cc

Subject

RE: [toaddb2beta] Schema Compare Issue

Classification

Hi Yvan,

There was a recent fix for the SQL0669N problem you saw. Please try the latest
beta and see if it resolves the problem.

I opened CR 70,718 to track the issue of Schema Compare Synchronize not
preserving target data.

Thanks,

Adam
att1.dat (25.5 KB)


#5

[ Attachment(s) from yroy@cmhc-schl.gc.ca included below]

Hi Adam,

The latest drop solved the SQL0669N issue but unfortunately introduced a new one
as well. For Naming Standard reason, we want to explicitly name our primary
index ( create table, create index and alter table to add primary key). The
Schema compare does not recreate our named primary key index so subsequent
compare still detect a missing index that we can’t create since DB2 implicitly
created an index to support the primary key constraint.

Let me know if need more info

Thanks

Yvan

First Compare generates:
and if we execute the DDL generated by the second compare here is what i get:

Adam Ririe
Sent by:

28/01/2010 11:05 AM

Please respond to
toaddb2beta@ yahoogroups. com

To

“toaddb2beta@ yahoogroups. com”

cc

Subject

RE: [toaddb2beta] Schema Compare Issue

Classification

Hi Yvan,

There was a recent fix for the SQL0669N problem you saw. Please try the latest
beta and see if it resolves the problem.

I opened CR 70,718 to track the issue of Schema Compare Synchronize not
preserving target data.

Thanks,

Adam
att1.dat (43 Bytes)


#6

[ Attachment(s) from yroy@cmhc-schl.gc.ca included below]

Hi Adam,

The latest drop solved the SQL0669N issue but unfortunately introduced a new one
as well. For Naming Standard reason, we want to explicitly name our primary
index ( create table, create index and alter table to add primary key). The
Schema compare does not recreate our named primary key index so subsequent
compare still detect a missing index that we can’t create since DB2 implicitly
created an index to support the primary key constraint.

Let me know if need more info

Thanks

Yvan

First Compare generates:
and if we execute the DDL generated by the second compare here is what i get:

Adam Ririe
Sent by:

28/01/2010 11:05 AM

Please respond to
toaddb2beta@ yahoogroups. com

To

“toaddb2beta@ yahoogroups. com”

cc

Subject

RE: [toaddb2beta] Schema Compare Issue

Classification

Hi Yvan,

There was a recent fix for the SQL0669N problem you saw. Please try the latest
beta and see if it resolves the problem.

I opened CR 70,718 to track the issue of Schema Compare Synchronize not
preserving target data.

Thanks,

Adam
image004.gif


#7

Hi Yvan,

CR 70,819 has been created to track this issue.

Thanks,

Adam
image001.gif (36.4 KB)


#8

Hi Yvan,

CR 70,819 has been created to track this issue.

Thanks,

Adam
image002.gif (25.5 KB)