We want to improve our database upgrade so that upon failure, customers
can more easily get back to their previous version while we look into
the problem. We sell a packaged product.
Currently, we export data into a homegrown format, create a new
database, and then import into the new database. We'd like to rid
ourselves of this intermediate, dangerous step (homegrown export
format). The reason it exists is that we used to support Access (Jet).
I'd like to do 'in-place' upgrades, more or less; leave the database
where it is, and tweak schema or data as needed. It seems a lot safer
and would certainly be much quicker.
I wanted to get ideas...what are some techniques that perhaps some of
you use?
Some of my thoughts:
* detach the old database, make a copy, attach to the copy. Upgrade the
copy, but on failure, reattach the original.
* Use DTS to move data from the old to the new. Don't switch to the new
until/unless it looks good.
* Put a transaction frame around the whole upgrade process and roll back
if it fails. Somehow, this sounds a little scary to me, though. Should it?
Other ideas? I'd love to hear more.
One of the goals is to not have the customer do anything manually in all
of this.
Do you know for sure that your customers are backing up their database and
that they are not making custom changes to the table structures? If so, then
you could feel more confident about deploying data change scripts.When you
make changes to a table design in Enterprise Manager, but don't click the
[Save] button, you can click the [Save Change Script] button to see what
T-SQL code EM is using to make the changes. It includes all the scripting
needed to insert / select existing data from a temporary table and also
wraps everything in a BEGIN.. END.. transaction. You could deploy the script
as is, or customize as needed.
"Mike Jones" <barker_djb@.yahoo.com> wrote in message
news:eqMNmLXBFHA.3504@.TK2MSFTNGP12.phx.gbl...
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should
it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.
|||This is how I always do it:
I create a change script using the database change management software DB
Ghost (http://www.dbghost.com).
I get all users off the database I'm about to change.
I back up the database I'm about to change.
I run the script.
I run the tests to verify that all is well.
I back up the database again so I have a backup before the changes and a
backup after the changes.
I open the database to all users.
"Mike Jones" wrote:
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.
>
|||This is harder to pull off with packaged software. We must send out a
setup program that users can run easily.
[vbcol=seagreen]
> This is how I always do it:
> I create a change script using the database change management software DB
> Ghost (http://www.dbghost.com).
> I get all users off the database I'm about to change.
> I back up the database I'm about to change.
> I run the script.
> I run the tests to verify that all is well.
> I back up the database again so I have a backup before the changes and a
> backup after the changes.
> I open the database to all users.
> "Mike Jones" wrote:
>
Showing posts with label version. Show all posts
Showing posts with label version. Show all posts
Wednesday, March 28, 2012
Robust database with easy rollback capability...
We want to improve our database upgrade so that upon failure, customers
can more easily get back to their previous version while we look into
the problem. We sell a packaged product.
Currently, we export data into a homegrown format, create a new
database, and then import into the new database. We'd like to rid
ourselves of this intermediate, dangerous step (homegrown export
format). The reason it exists is that we used to support Access (Jet).
I'd like to do 'in-place' upgrades, more or less; leave the database
where it is, and tweak schema or data as needed. It seems a lot safer
and would certainly be much quicker.
I wanted to get ideas...what are some techniques that perhaps some of
you use?
Some of my thoughts:
* detach the old database, make a copy, attach to the copy. Upgrade the
copy, but on failure, reattach the original.
* Use DTS to move data from the old to the new. Don't switch to the new
until/unless it looks good.
* Put a transaction frame around the whole upgrade process and roll back
if it fails. Somehow, this sounds a little scary to me, though. Should it?
Other ideas? I'd love to hear more.
One of the goals is to not have the customer do anything manually in all
of this.Do you know for sure that your customers are backing up their database and
that they are not making custom changes to the table structures? If so, then
you could feel more confident about deploying data change scripts.When you
make changes to a table design in Enterprise Manager, but don't click the
[Save] button, you can click the [Save Change Script] button to see what
T-SQL code EM is using to make the changes. It includes all the scripting
needed to insert / select existing data from a temporary table and also
wraps everything in a BEGIN.. END.. transaction. You could deploy the script
as is, or customize as needed.
"Mike Jones" <barker_djb@.yahoo.com> wrote in message
news:eqMNmLXBFHA.3504@.TK2MSFTNGP12.phx.gbl...
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should
it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.|||This is how I always do it:
I create a change script using the database change management software DB
Ghost (http://www.dbghost.com).
I get all users off the database I'm about to change.
I back up the database I'm about to change.
I run the script.
I run the tests to verify that all is well.
I back up the database again so I have a backup before the changes and a
backup after the changes.
I open the database to all users.
"Mike Jones" wrote:
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.
>|||This is harder to pull off with packaged software. We must send out a
setup program that users can run easily.
> This is how I always do it:
> I create a change script using the database change management software DB
> Ghost (http://www.dbghost.com).
> I get all users off the database I'm about to change.
> I back up the database I'm about to change.
> I run the script.
> I run the tests to verify that all is well.
> I back up the database again so I have a backup before the changes and a
> backup after the changes.
> I open the database to all users.
> "Mike Jones" wrote:
>
>>We want to improve our database upgrade so that upon failure, customers
>>can more easily get back to their previous version while we look into
>>the problem. We sell a packaged product.
>>Currently, we export data into a homegrown format, create a new
>>database, and then import into the new database. We'd like to rid
>>ourselves of this intermediate, dangerous step (homegrown export
>>format). The reason it exists is that we used to support Access (Jet).
>>I'd like to do 'in-place' upgrades, more or less; leave the database
>>where it is, and tweak schema or data as needed. It seems a lot safer
>>and would certainly be much quicker.
>>I wanted to get ideas...what are some techniques that perhaps some of
>>you use?
>>Some of my thoughts:
>>* detach the old database, make a copy, attach to the copy. Upgrade the
>>copy, but on failure, reattach the original.
>>* Use DTS to move data from the old to the new. Don't switch to the new
>>until/unless it looks good.
>>* Put a transaction frame around the whole upgrade process and roll back
>>if it fails. Somehow, this sounds a little scary to me, though. Should it?
>>Other ideas? I'd love to hear more.
>>One of the goals is to not have the customer do anything manually in all
>>of this.
can more easily get back to their previous version while we look into
the problem. We sell a packaged product.
Currently, we export data into a homegrown format, create a new
database, and then import into the new database. We'd like to rid
ourselves of this intermediate, dangerous step (homegrown export
format). The reason it exists is that we used to support Access (Jet).
I'd like to do 'in-place' upgrades, more or less; leave the database
where it is, and tweak schema or data as needed. It seems a lot safer
and would certainly be much quicker.
I wanted to get ideas...what are some techniques that perhaps some of
you use?
Some of my thoughts:
* detach the old database, make a copy, attach to the copy. Upgrade the
copy, but on failure, reattach the original.
* Use DTS to move data from the old to the new. Don't switch to the new
until/unless it looks good.
* Put a transaction frame around the whole upgrade process and roll back
if it fails. Somehow, this sounds a little scary to me, though. Should it?
Other ideas? I'd love to hear more.
One of the goals is to not have the customer do anything manually in all
of this.Do you know for sure that your customers are backing up their database and
that they are not making custom changes to the table structures? If so, then
you could feel more confident about deploying data change scripts.When you
make changes to a table design in Enterprise Manager, but don't click the
[Save] button, you can click the [Save Change Script] button to see what
T-SQL code EM is using to make the changes. It includes all the scripting
needed to insert / select existing data from a temporary table and also
wraps everything in a BEGIN.. END.. transaction. You could deploy the script
as is, or customize as needed.
"Mike Jones" <barker_djb@.yahoo.com> wrote in message
news:eqMNmLXBFHA.3504@.TK2MSFTNGP12.phx.gbl...
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should
it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.|||This is how I always do it:
I create a change script using the database change management software DB
Ghost (http://www.dbghost.com).
I get all users off the database I'm about to change.
I back up the database I'm about to change.
I run the script.
I run the tests to verify that all is well.
I back up the database again so I have a backup before the changes and a
backup after the changes.
I open the database to all users.
"Mike Jones" wrote:
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.
>|||This is harder to pull off with packaged software. We must send out a
setup program that users can run easily.
> This is how I always do it:
> I create a change script using the database change management software DB
> Ghost (http://www.dbghost.com).
> I get all users off the database I'm about to change.
> I back up the database I'm about to change.
> I run the script.
> I run the tests to verify that all is well.
> I back up the database again so I have a backup before the changes and a
> backup after the changes.
> I open the database to all users.
> "Mike Jones" wrote:
>
>>We want to improve our database upgrade so that upon failure, customers
>>can more easily get back to their previous version while we look into
>>the problem. We sell a packaged product.
>>Currently, we export data into a homegrown format, create a new
>>database, and then import into the new database. We'd like to rid
>>ourselves of this intermediate, dangerous step (homegrown export
>>format). The reason it exists is that we used to support Access (Jet).
>>I'd like to do 'in-place' upgrades, more or less; leave the database
>>where it is, and tweak schema or data as needed. It seems a lot safer
>>and would certainly be much quicker.
>>I wanted to get ideas...what are some techniques that perhaps some of
>>you use?
>>Some of my thoughts:
>>* detach the old database, make a copy, attach to the copy. Upgrade the
>>copy, but on failure, reattach the original.
>>* Use DTS to move data from the old to the new. Don't switch to the new
>>until/unless it looks good.
>>* Put a transaction frame around the whole upgrade process and roll back
>>if it fails. Somehow, this sounds a little scary to me, though. Should it?
>>Other ideas? I'd love to hear more.
>>One of the goals is to not have the customer do anything manually in all
>>of this.
Robust database with easy rollback capability...
We want to improve our database upgrade so that upon failure, customers
can more easily get back to their previous version while we look into
the problem. We sell a packaged product.
Currently, we export data into a homegrown format, create a new
database, and then import into the new database. We'd like to rid
ourselves of this intermediate, dangerous step (homegrown export
format). The reason it exists is that we used to support Access (Jet).
I'd like to do 'in-place' upgrades, more or less; leave the database
where it is, and tweak schema or data as needed. It seems a lot safer
and would certainly be much quicker.
I wanted to get ideas...what are some techniques that perhaps some of
you use?
Some of my thoughts:
* detach the old database, make a copy, attach to the copy. Upgrade the
copy, but on failure, reattach the original.
* Use DTS to move data from the old to the new. Don't switch to the new
until/unless it looks good.
* Put a transaction frame around the whole upgrade process and roll back
if it fails. Somehow, this sounds a little scary to me, though. Should it?
Other ideas? I'd love to hear more.
One of the goals is to not have the customer do anything manually in all
of this.Do you know for sure that your customers are backing up their database and
that they are not making custom changes to the table structures? If so, then
you could feel more confident about deploying data change scripts.When you
make changes to a table design in Enterprise Manager, but don't click the
[Save] button, you can click the [Save Change Script] button to see
what
T-SQL code EM is using to make the changes. It includes all the scripting
needed to insert / select existing data from a temporary table and also
wraps everything in a BEGIN.. END.. transaction. You could deploy the script
as is, or customize as needed.
"Mike Jones" <barker_djb@.yahoo.com> wrote in message
news:eqMNmLXBFHA.3504@.TK2MSFTNGP12.phx.gbl...
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should
it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.|||This is how I always do it:
I create a change script using the database change management software DB
Ghost (http://www.dbghost.com).
I get all users off the database I'm about to change.
I back up the database I'm about to change.
I run the script.
I run the tests to verify that all is well.
I back up the database again so I have a backup before the changes and a
backup after the changes.
I open the database to all users.
"Mike Jones" wrote:
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should i
t?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.
>|||This is harder to pull off with packaged software. We must send out a
setup program that users can run easily.
[vbcol=seagreen]
> This is how I always do it:
> I create a change script using the database change management software DB
> Ghost (http://www.dbghost.com).
> I get all users off the database I'm about to change.
> I back up the database I'm about to change.
> I run the script.
> I run the tests to verify that all is well.
> I back up the database again so I have a backup before the changes and a
> backup after the changes.
> I open the database to all users.
> "Mike Jones" wrote:
>
can more easily get back to their previous version while we look into
the problem. We sell a packaged product.
Currently, we export data into a homegrown format, create a new
database, and then import into the new database. We'd like to rid
ourselves of this intermediate, dangerous step (homegrown export
format). The reason it exists is that we used to support Access (Jet).
I'd like to do 'in-place' upgrades, more or less; leave the database
where it is, and tweak schema or data as needed. It seems a lot safer
and would certainly be much quicker.
I wanted to get ideas...what are some techniques that perhaps some of
you use?
Some of my thoughts:
* detach the old database, make a copy, attach to the copy. Upgrade the
copy, but on failure, reattach the original.
* Use DTS to move data from the old to the new. Don't switch to the new
until/unless it looks good.
* Put a transaction frame around the whole upgrade process and roll back
if it fails. Somehow, this sounds a little scary to me, though. Should it?
Other ideas? I'd love to hear more.
One of the goals is to not have the customer do anything manually in all
of this.Do you know for sure that your customers are backing up their database and
that they are not making custom changes to the table structures? If so, then
you could feel more confident about deploying data change scripts.When you
make changes to a table design in Enterprise Manager, but don't click the
[Save] button, you can click the [Save Change Script] button to see
what
T-SQL code EM is using to make the changes. It includes all the scripting
needed to insert / select existing data from a temporary table and also
wraps everything in a BEGIN.. END.. transaction. You could deploy the script
as is, or customize as needed.
"Mike Jones" <barker_djb@.yahoo.com> wrote in message
news:eqMNmLXBFHA.3504@.TK2MSFTNGP12.phx.gbl...
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should
it?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.|||This is how I always do it:
I create a change script using the database change management software DB
Ghost (http://www.dbghost.com).
I get all users off the database I'm about to change.
I back up the database I'm about to change.
I run the script.
I run the tests to verify that all is well.
I back up the database again so I have a backup before the changes and a
backup after the changes.
I open the database to all users.
"Mike Jones" wrote:
> We want to improve our database upgrade so that upon failure, customers
> can more easily get back to their previous version while we look into
> the problem. We sell a packaged product.
> Currently, we export data into a homegrown format, create a new
> database, and then import into the new database. We'd like to rid
> ourselves of this intermediate, dangerous step (homegrown export
> format). The reason it exists is that we used to support Access (Jet).
> I'd like to do 'in-place' upgrades, more or less; leave the database
> where it is, and tweak schema or data as needed. It seems a lot safer
> and would certainly be much quicker.
> I wanted to get ideas...what are some techniques that perhaps some of
> you use?
> Some of my thoughts:
> * detach the old database, make a copy, attach to the copy. Upgrade the
> copy, but on failure, reattach the original.
> * Use DTS to move data from the old to the new. Don't switch to the new
> until/unless it looks good.
> * Put a transaction frame around the whole upgrade process and roll back
> if it fails. Somehow, this sounds a little scary to me, though. Should i
t?
> Other ideas? I'd love to hear more.
> One of the goals is to not have the customer do anything manually in all
> of this.
>|||This is harder to pull off with packaged software. We must send out a
setup program that users can run easily.
[vbcol=seagreen]
> This is how I always do it:
> I create a change script using the database change management software DB
> Ghost (http://www.dbghost.com).
> I get all users off the database I'm about to change.
> I back up the database I'm about to change.
> I run the script.
> I run the tests to verify that all is well.
> I back up the database again so I have a backup before the changes and a
> backup after the changes.
> I open the database to all users.
> "Mike Jones" wrote:
>
Tuesday, March 20, 2012
Reverting From MSSQL 2005 to 2000-Help please....
I have installed MSSQL 2005 on my D: drive of my windows 2003 server, but now need to install MSSQL version 2000 b/c I realized I have one less license than I thought I had. I have build no databases, only the default information. Can I install another instance (being the 2000 instance) on the same drive? If I can't, can I install it on the C
It 'should' be OK to have both versions.
However, if you are not planning to use the SQL 2005 because of licensing issues, it may prove easier to just remove it. (My attitude is that if there is no license for it, then it shouldn't be on a computer (who knows when the licenising 'police' may show up...)
|||There are no problems running SQL 2005 and SQL 2000 on the same machine and the same drive.
Subscribe to:
Posts (Atom)