Options
Tables not registering
Brian Donahue
Posts: 6,590 Bronze 1
Hi Peter,
I've got the scripts of the tables you've sent me and I am working to
find the problem.
Regards,
Brian Donahue
Red Gate Technical Support
"Peter Thistleton" <peter.thistleton@achievehealthcare.com> wrote in message
news:Pv$%237JaVDHA.1200@server53...
> I have a few tables which used to register and compare (though not
properly
> because they have text columns) in version 2.03. I installed version 3.0
> today and these tables no longer display. What criteria would exclude
these
> from the compare. It has a compound primary key and two text columns but
> besides that is about as normal as can be.
>
>
I've got the scripts of the tables you've sent me and I am working to
find the problem.
Regards,
Brian Donahue
Red Gate Technical Support
"Peter Thistleton" <peter.thistleton@achievehealthcare.com> wrote in message
news:Pv$%237JaVDHA.1200@server53...
> I have a few tables which used to register and compare (though not
properly
> because they have text columns) in version 2.03. I installed version 3.0
> today and these tables no longer display. What criteria would exclude
these
> from the compare. It has a compound primary key and two text columns but
> besides that is about as normal as can be.
>
>
This discussion has been closed.
Comments
There is a problem with the way that Data Compare 3 indexes multiple
primary keys. There will be an update released today in Bundle version 2.51
that will fix that problem as well as the bundle installation problems that
have been occurring.
Regards,
Brian Donahue
Red Gate Technical Support
"Grant Fritchey" <grant.fritchey@fmglobal.com> wrote in message
news:zzvZ0YKaDHA.1288@server53...
> We've discovered that we're getting the same problem on other tables as
> well. It looks like a number of them simply have system generated PK names
> and since we're comparing tables with two different pk names... I renamed
> some of the pk's and got the tables to register, but some tables didn't
> register even after changing the PK names, and the compound key tables
> didn't have this problem to begin with.
>
> I've sent two emails to tech support. I still haven't recieved a message
> back on either of them. I'm going to try calling later today if I don't
get
> an answer.
>
> I see Lockwood Tech has a new tool out that does data compare.......
> "Peter Thistleton" <peter.thistleton@achievehealthcare.com> wrote in
message
> news:Pv$%237JaVDHA.1200@server53...
> > I have a few tables which used to register and compare (though not
> properly
> > because they have text columns) in version 2.03. I installed version
3.0
> > today and these tables no longer display. What criteria would exclude
> these
> > from the compare. It has a compound primary key and two text columns
but
> > besides that is about as normal as can be.
> >
> >
>
>
I can confirm that. If you've got a different name on the index, you
can't select the table 100% of the time.
I've let development know, so I should have an answer for you soon.
Regards,
Brian Donahue
Technical Support
"Grant Fritchey" <grant.fritchey@fmglobal.com> wrote in message
news:W2r8PbxaDHA.700@server53...
> Thanks for the reply.
>
> I went and downloaded it today. I've now got version 3.01, Build 142. Is
> that correct? If so, it looks like you fixed the multi-column key issue.
I'm
> still seeing another possibly problem. We have a few tables that were
> created using system created PK names. That means that a table on System1
> has a different PK name than a table on System 2. When that happens, the
> tables don't show up on the list of comparable tables (just like the old
> problem with multi-column keys). It does look like simply getting the PK
> names to match fixes this problem(?), but it does seem like the tool would
> be able to adjust to the use of system defaults.
>
> Thanks,
>
> Grant
> "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
> news:kBiHzmLaDHA.1284@server53...
> > Hi Grant,
> >
> > There is a problem with the way that Data Compare 3 indexes multiple
> > primary keys. There will be an update released today in Bundle version
> 2.51
> > that will fix that problem as well as the bundle installation problems
> that
> > have been occurring.
> >
> > Regards,
> >
> > Brian Donahue
> > Red Gate Technical Support
> >
> > "Grant Fritchey" <grant.fritchey@fmglobal.com> wrote in message
> > news:zzvZ0YKaDHA.1288@server53...
> > > We've discovered that we're getting the same problem on other tables
as
> > > well. It looks like a number of them simply have system generated PK
> names
> > > and since we're comparing tables with two different pk names... I
> renamed
> > > some of the pk's and got the tables to register, but some tables
didn't
> > > register even after changing the PK names, and the compound key tables
> > > didn't have this problem to begin with.
> > >
> > > I've sent two emails to tech support. I still haven't recieved a
message
> > > back on either of them. I'm going to try calling later today if I
don't
> > get
> > > an answer.
> > >
> > > I see Lockwood Tech has a new tool out that does data compare.......
> > > "Peter Thistleton" <peter.thistleton@achievehealthcare.com> wrote in
> > message
> > > news:Pv$%237JaVDHA.1200@server53...
> > > > I have a few tables which used to register and compare (though not
> > > properly
> > > > because they have text columns) in version 2.03. I installed
version
> > 3.0
> > > > today and these tables no longer display. What criteria would
exclude
> > > these
> > > > from the compare. It has a compound primary key and two text
columns
> > but
> > > > besides that is about as normal as can be.
> > > >
> > > >
> > >
> > >
> >
> >
>
>