Options
2 possible bugs in SQL Compare v2.03
Brian Donahue
Posts: 6,590 Bronze 1
Hi Rich,
The second issue is easy to fix. It should compare cascading update and
delete settings properly if the 'Create SQL 7 compatible scripts' option is
deselected.
The first issue, I'll have to look a little deeper into. It could be an
oversight, or there could be a legitimate reason for it.
Thanks,
Brian Donahue
Red Gate Technical Support
"Rich Klein" <noone@nowhere.com> wrote in message
news:1GN0oqtKDHA.1172@server53...
> Hello,
>
> We have encountered two different problem scenarios while using SQL
Compare
> v2.03.
>
> 1) Comparing triggers owned by a user other then 'dbo'. The generated
DROP
> TRIGGER statement in the update script does not qualify the trigger name
> with its owner. So if the trigger is owned by 'joe', but the update is
run
> by 'dbo', it fails.
>
> 2) Comparing foreign key constraints where the first is set to CASCADE
> DELETE or CASCADE UPDATE, and the second is not, they will show up as '='
in
> the Compare even though they are not.
>
> Are these known issues?
>
> Regards
>
>
The second issue is easy to fix. It should compare cascading update and
delete settings properly if the 'Create SQL 7 compatible scripts' option is
deselected.
The first issue, I'll have to look a little deeper into. It could be an
oversight, or there could be a legitimate reason for it.
Thanks,
Brian Donahue
Red Gate Technical Support
"Rich Klein" <noone@nowhere.com> wrote in message
news:1GN0oqtKDHA.1172@server53...
> Hello,
>
> We have encountered two different problem scenarios while using SQL
Compare
> v2.03.
>
> 1) Comparing triggers owned by a user other then 'dbo'. The generated
DROP
> TRIGGER statement in the update script does not qualify the trigger name
> with its owner. So if the trigger is owned by 'joe', but the update is
run
> by 'dbo', it fails.
>
> 2) Comparing foreign key constraints where the first is set to CASCADE
> DELETE or CASCADE UPDATE, and the second is not, they will show up as '='
in
> the Compare even though they are not.
>
> Are these known issues?
>
> Regards
>
>
This discussion has been closed.
Comments
Well, the trigger owner problem is not a bug. Let's call it missing
functionality. It will check for this in the next version and deal with it
properly.
Regards,
Brian Donahue
"Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
news:Xss72UBLDHA.1424@server53...
> Hi Rich,
>
> The second issue is easy to fix. It should compare cascading update
and
> delete settings properly if the 'Create SQL 7 compatible scripts' option
is
> deselected.
>
> The first issue, I'll have to look a little deeper into. It could be
an
> oversight, or there could be a legitimate reason for it.
>
> Thanks,
> Brian Donahue
> Red Gate Technical Support
>
> "Rich Klein" <noone@nowhere.com> wrote in message
> news:1GN0oqtKDHA.1172@server53...
> > Hello,
> >
> > We have encountered two different problem scenarios while using SQL
> Compare
> > v2.03.
> >
> > 1) Comparing triggers owned by a user other then 'dbo'. The generated
> DROP
> > TRIGGER statement in the update script does not qualify the trigger name
> > with its owner. So if the trigger is owned by 'joe', but the update is
> run
> > by 'dbo', it fails.
> >
> > 2) Comparing foreign key constraints where the first is set to CASCADE
> > DELETE or CASCADE UPDATE, and the second is not, they will show up as
'='
> in
> > the Compare even though they are not.
> >
> > Are these known issues?
> >
> > Regards
> >
> >
>
>