New approach to dependency info in 3.15
Brian Donahue
Posts: 6,590 Bronze 1
Hi Chris,
I doubt that the patch would speed anything up -- it was written just to
keep the software from locking up while reading comments. We did realize
that the new dependency routine would slow things down a bit, but was well
worth the effort in order to create more accurate scripts.
The versions previous to 3.15 used to query the sysdepends table to
build up a dependency matrix, but the information in sysdepends is done at
object create time and would be inaccurate if, for instance, a parent object
was created after a child object.
Regards,
Brian Donahue
Red Gate Technical Support
"Chris Tybur" <ctybur@infinitevisions.com> wrote in message
news:OlZ8WE$JEHA.3268@server53...
> Regarding how the comparison engine now builds a dependency matrix when
> scripting databases, is there any way this feature might become optional
> in the future? The reason I ask is my company has an app that uses the
> toolkit, and we're updating it to VB.NET to use the newer, much faster
> comparison engine. However, with version 3.15 we've lost nearly all the
> time savings we gained due to the new dependency architecture. Red Gate
> will no doubt continue to make improvements to the comparison engine
> which we will probably want to take advantage of, but it will be hard to
> do so because of the way dependency information is now being handled.
>
> I've tried registering a database through code with version 3.15 and it
> took about 12 minutes to get past the 'Reading comments' stage, though
> it was able to completely finish. Could this be a symptom of the recent
> problem noted here with SQL Compare freezing at that stage? Might the
> patch to fix it also reduce the 12 minutes it takes my app to register a
> database? Have any other toolkit users experienced that kind of delay
> when registering databases with 3.15?
>
> Chris Tybur
>
I doubt that the patch would speed anything up -- it was written just to
keep the software from locking up while reading comments. We did realize
that the new dependency routine would slow things down a bit, but was well
worth the effort in order to create more accurate scripts.
The versions previous to 3.15 used to query the sysdepends table to
build up a dependency matrix, but the information in sysdepends is done at
object create time and would be inaccurate if, for instance, a parent object
was created after a child object.
Regards,
Brian Donahue
Red Gate Technical Support
"Chris Tybur" <ctybur@infinitevisions.com> wrote in message
news:OlZ8WE$JEHA.3268@server53...
> Regarding how the comparison engine now builds a dependency matrix when
> scripting databases, is there any way this feature might become optional
> in the future? The reason I ask is my company has an app that uses the
> toolkit, and we're updating it to VB.NET to use the newer, much faster
> comparison engine. However, with version 3.15 we've lost nearly all the
> time savings we gained due to the new dependency architecture. Red Gate
> will no doubt continue to make improvements to the comparison engine
> which we will probably want to take advantage of, but it will be hard to
> do so because of the way dependency information is now being handled.
>
> I've tried registering a database through code with version 3.15 and it
> took about 12 minutes to get past the 'Reading comments' stage, though
> it was able to completely finish. Could this be a symptom of the recent
> problem noted here with SQL Compare freezing at that stage? Might the
> patch to fix it also reduce the 12 minutes it takes my app to register a
> database? Have any other toolkit users experienced that kind of delay
> when registering databases with 3.15?
>
> Chris Tybur
>
This discussion has been closed.
Comments
I had a bit of a chat with the programmers about this, and we're
probably not going to go back to using sysdepends or put an option in for
using sysdepends to keep the complexity of the software down. Since the new
dependendency routine solves so many problems, we'll probably keep it going,
and there would be a bit of overhead for ourselves if we maintained two
distinct dependency routines.
Regards,
Brian Donahue
Red Gate Technical Support
"Chris Tybur" <ctybur@infinitevisions.com> wrote in message
news:grKgTBVKEHA.2756@server53...
> Just a quick follow-up...
>
> I wrote a utility using the toolkit that basically recreates an entire
> database schema from scratch. We run this utility on our databases when
> we do a build of our software. The new databases all have correct info
> in their sysdepends tables, and at that point we script them into a
> workspace file that ships with our database conversion program. This way
> SQL Compare will always do things in the right order.
>
> With 3.15, SQL Compare basically does what my utility does, only the
> time is spent at the customer end of the process rather than the build
> end. I would much rather expend that time at the build end if possible.
> If you had to radically alter the architecture of the comparison library
> to incorporate the new dependecy logic, I can understand it not being
> optional. But if making it optional were possible, it would be a big
> time savings for my customers.
>
> Chris
>
> Brian Donahue (Red Gate) wrote:
> > Hi Chris,
> >
> > I doubt that the patch would speed anything up -- it was written
just to
> > keep the software from locking up while reading comments. We did realize
> > that the new dependency routine would slow things down a bit, but was
well
> > worth the effort in order to create more accurate scripts.
> >
> > The versions previous to 3.15 used to query the sysdepends table to
> > build up a dependency matrix, but the information in sysdepends is done
at
> > object create time and would be inaccurate if, for instance, a parent
object
> > was created after a child object.
> >
> > Regards,
> >
> > Brian Donahue
> > Red Gate Technical Support
> >
> > "Chris Tybur" <ctybur@infinitevisions.com> wrote in message
> > news:OlZ8WE$JEHA.3268@server53...
> >
> >>Regarding how the comparison engine now builds a dependency matrix when
> >>scripting databases, is there any way this feature might become optional
> >>in the future? The reason I ask is my company has an app that uses the
> >>toolkit, and we're updating it to VB.NET to use the newer, much faster
> >>comparison engine. However, with version 3.15 we've lost nearly all the
> >>time savings we gained due to the new dependency architecture. Red Gate
> >>will no doubt continue to make improvements to the comparison engine
> >>which we will probably want to take advantage of, but it will be hard to
> >>do so because of the way dependency information is now being handled.
> >>
> >>I've tried registering a database through code with version 3.15 and it
> >>took about 12 minutes to get past the 'Reading comments' stage, though
> >>it was able to completely finish. Could this be a symptom of the recent
> >>problem noted here with SQL Compare freezing at that stage? Might the
> >>patch to fix it also reduce the 12 minutes it takes my app to register a
> >>database? Have any other toolkit users experienced that kind of delay
> >>when registering databases with 3.15?
> >>
> >>Chris Tybur
> >>
> >
> >
> >
>
It shouldn't be *that much* slower with the new dependency routine.
Are you actually running the application in the Visual Studio IDE in
debug build mode? That would slow it down quite a bit.
Regards,
Brian Donahue
Red Gate Technical Support
"Chris Tybur" <ctybur@infinitevisions.com> wrote in message
news:knrg%23%23ILEHA.1240@server53...
> Sounds fine. How about the possibility of speeding up the building of
> the dependency matrix at some point?
>
> Chris
>
> Brian Donahue (Red Gate) wrote:
>
> > Hi Chris,
> >
> > I had a bit of a chat with the programmers about this, and we're
> > probably not going to go back to using sysdepends or put an option in
for
> > using sysdepends to keep the complexity of the software down. Since the
new
> > dependendency routine solves so many problems, we'll probably keep it
going,
> > and there would be a bit of overhead for ourselves if we maintained two
> > distinct dependency routines.
> >
> >
> > Regards,
> >
> > Brian Donahue
> > Red Gate Technical Support
> >
> > "Chris Tybur" <ctybur@infinitevisions.com> wrote in message
> > news:grKgTBVKEHA.2756@server53...
> >
> >>Just a quick follow-up...
> >>
> >>I wrote a utility using the toolkit that basically recreates an entire
> >>database schema from scratch. We run this utility on our databases when
> >>we do a build of our software. The new databases all have correct info
> >>in their sysdepends tables, and at that point we script them into a
> >>workspace file that ships with our database conversion program. This way
> >>SQL Compare will always do things in the right order.
> >>
> >>With 3.15, SQL Compare basically does what my utility does, only the
> >>time is spent at the customer end of the process rather than the build
> >>end. I would much rather expend that time at the build end if possible.
> >>If you had to radically alter the architecture of the comparison library
> >>to incorporate the new dependecy logic, I can understand it not being
> >>optional. But if making it optional were possible, it would be a big
> >>time savings for my customers.
> >>
> >>Chris
> >>
> >>Brian Donahue (Red Gate) wrote:
> >>
> >>>Hi Chris,
> >>>
> >>> I doubt that the patch would speed anything up -- it was written
> >
> > just to
> >
> >>>keep the software from locking up while reading comments. We did
realize
> >>>that the new dependency routine would slow things down a bit, but was
> >
> > well
> >
> >>>worth the effort in order to create more accurate scripts.
> >>>
> >>> The versions previous to 3.15 used to query the sysdepends table to
> >>>build up a dependency matrix, but the information in sysdepends is done
> >
> > at
> >
> >>>object create time and would be inaccurate if, for instance, a parent
> >
> > object
> >
> >>>was created after a child object.
> >>>
> >>>Regards,
> >>>
> >>>Brian Donahue
> >>>Red Gate Technical Support
> >>>
> >>>"Chris Tybur" <ctybur@infinitevisions.com> wrote in message
> >>>news:OlZ8WE$JEHA.3268@server53...
> >>>
> >>>
> >>>>Regarding how the comparison engine now builds a dependency matrix
when
> >>>>scripting databases, is there any way this feature might become
optional
> >>>>in the future? The reason I ask is my company has an app that uses the
> >>>>toolkit, and we're updating it to VB.NET to use the newer, much faster
> >>>>comparison engine. However, with version 3.15 we've lost nearly all
the
> >>>>time savings we gained due to the new dependency architecture. Red
Gate
> >>>>will no doubt continue to make improvements to the comparison engine
> >>>>which we will probably want to take advantage of, but it will be hard
to
> >>>>do so because of the way dependency information is now being handled.
> >>>>
> >>>>I've tried registering a database through code with version 3.15 and
it
> >>>>took about 12 minutes to get past the 'Reading comments' stage, though
> >>>>it was able to completely finish. Could this be a symptom of the
recent
> >>>>problem noted here with SQL Compare freezing at that stage? Might the
> >>>>patch to fix it also reduce the 12 minutes it takes my app to register
a
> >>>>database? Have any other toolkit users experienced that kind of delay
> >>>>when registering databases with 3.15?
> >>>>
> >>>>Chris Tybur
> >>>>
> >>>
> >>>
> >>>
> >
> >
>