New approach to dependency info in 3.15

Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
edited April 28, 2004 8:39AM in SQL Toolkit Previous Versions
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
>

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    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
    > >>
    > >
    > >
    > >
    >
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Chris,

    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
    > >>>>
    > >>>
    > >>>
    > >>>
    > >
    > >
    >
This discussion has been closed.