Hi,

We are just going thru an upgrade exercise taking our SQL2005 build 3175
upto build 3239. We have upgraded development servers and are about to
upgrade the acceptance testing level next week. I try not to get the
workstation clirnt tools build ahead of the server client tools build so our
migration workstations will not be upgraded until the time we upgrade our
production servers to build 3239.

Is this a good idea or am I too controlling? What do others do during an
upgrade?

Thanks

Chris

I try to make sure that all clients and all servers are operating at the
same level under normal circumstances. During an upgrade, I always apply
patches to my workstation first (to make sure they don't blow up a more
important machine), and so in the short term I am always a little ahead of
the rest of the servers. But this state doesn't last for long. Similarly,
all of the lower-level servers are upgraded (both engine and client tools)
before production servers see any of it. But again, this state is
short-lived unless the initial deployment leads us to believe that more
rigorous testing might be required.

A


"Chris Wood" <anonymous@microsoft.com> wrote in message
news:u$hrKMqtIHA.5472@TK2MSFTNGP06.phx.gbl...
> Hi,
>
> We are just going thru an upgrade exercise taking our SQL2005 build 3175
> upto build 3239. We have upgraded development servers and are about to
> upgrade the acceptance testing level next week. I try not to get the
> workstation clirnt tools build ahead of the server client tools build so
> our migration workstations will not be upgraded until the time we upgrade
> our production servers to build 3239.
>
> Is this a good idea or am I too controlling? What do others do during an
> upgrade?
>
> Thanks
>
> Chris
>

Aaron,

My timeframe is 8 weeks from development to production with 3 weeks between
development and acceptance. (You can see where most testing gets done). I
would upgrade the developers and acceptance testers workstations when
acceptance gets upgraded but not say workstations that migrate code to
production until the production upgrade. Is this too controlling? I can see
that SSIS and some other tools like SQLCMD and BCP have been updated by the
newer build.

Thanks

Chris

"Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:erJ4MQqtIHA.3804@TK2MSFTNGP02.phx.gbl...
>I try to make sure that all clients and all servers are operating at the
>same level under normal circumstances. During an upgrade, I always apply
>patches to my workstation first (to make sure they don't blow up a more
>important machine), and so in the short term I am always a little ahead of
>the rest of the servers. But this state doesn't last for long. Similarly,
>all of the lower-level servers are upgraded (both engine and client tools)
>before production servers see any of it. But again, this state is
>short-lived unless the initial deployment leads us to believe that more
>rigorous testing might be required.
>
> A
>
>
> "Chris Wood" <anonymous@microsoft.com> wrote in message
> news:u$hrKMqtIHA.5472@TK2MSFTNGP06.phx.gbl...
>> Hi,
>>
>> We are just going thru an upgrade exercise taking our SQL2005 build 3175
>> upto build 3239. We have upgraded development servers and are about to
>> upgrade the acceptance testing level next week. I try not to get the
>> workstation clirnt tools build ahead of the server client tools build so
>> our migration workstations will not be upgraded until the time we upgrade
>> our production servers to build 3239.
>>
>> Is this a good idea or am I too controlling? What do others do during an
>> upgrade?
>>
>> Thanks
>>
>> Chris
>>
>
>

The only danger zone I see there is SSIS (if you are using it). I highly
doubt the changes to SQLCMD / BCP would be breaking changes. Are you being
too controlling? I have no idea. Does this process interfere with anyone
else's job except yours? If so, then maybe you should ask them? :-)




"Chris Wood" <anonymous@microsoft.com> wrote in message
news:uv5RmVqtIHA.5268@TK2MSFTNGP06.phx.gbl...
> Aaron,
>
> My timeframe is 8 weeks from development to production with 3 weeks
> between development and acceptance. (You can see where most testing gets
> done). I would upgrade the developers and acceptance testers workstations
> when acceptance gets upgraded but not say workstations that migrate code
> to production until the production upgrade. Is this too controlling? I can
> see that SSIS and some other tools like SQLCMD and BCP have been updated
> by the newer build.
>
> Thanks

Thanks for your , as always Aaron. It sounds like just be carefull if
there are SSIS packages involved.

Chris

"Aaron Bertrand [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:O$XubYqtIHA.3716@TK2MSFTNGP05.phx.gbl...
> The only danger zone I see there is SSIS (if you are using it). I highly
> doubt the changes to SQLCMD / BCP would be breaking changes. Are you
> being too controlling? I have no idea. Does this process interfere with
> anyone else's job except yours? If so, then maybe you should ask them?
> :-)
>
>
>
>
> "Chris Wood" <anonymous@microsoft.com> wrote in message
> news:uv5RmVqtIHA.5268@TK2MSFTNGP06.phx.gbl...
>> Aaron,
>>
>> My timeframe is 8 weeks from development to production with 3 weeks
>> between development and acceptance. (You can see where most testing gets
>> done). I would upgrade the developers and acceptance testers workstations
>> when acceptance gets upgraded but not say workstations that migrate code
>> to production until the production upgrade. Is this too controlling? I
>> can see that SSIS and some other tools like SQLCMD and BCP have been
>> updated by the newer build.
>>
>> Thanks
>
>