Hi all,
Can anyone advise on installing multiple versions of
SqlServer 2000 (ver 8) on the same server whilst
maintaining the integrity of previous installations of
SqlServer ?
Thanks in advance.
jTHere are no integrity issues involving multiple instances on the same box,
one instance is independent of the other, with one exception... - they both
will compete for memory. So unless you will be running only one at a time, I
would advise you to set max memory for each instance, assigning the
appropriate memory, so the instances do not compete in this regard...
"jimA" <jima@.pt.lu> wrote in message
news:075a01c35cc1$b7c0df60$a601280a@.phx.gbl...
> Hi all,
> Can anyone advise on installing multiple versions of
> SqlServer 2000 (ver 8) on the same server whilst
> maintaining the integrity of previous installations of
> SqlServer ?
> Thanks in advance.
> j|||You can install multiple instance of SQL 2000 on the same server. Each
is independent and can be at different service pack levels. Only the
tools are shared.
It's generally best to deploy a single instance unless you have a
specific reason to do otherwise, such as special security isolation
requirements or independent test environments. See the Books Online
<architec.chm::/8_ar_cs_5upf.htm> for recommendations. Also note that
licensing restrictions vary by edition.
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"jimA" <jima@.pt.lu> wrote in message
news:075a01c35cc1$b7c0df60$a601280a@.phx.gbl...
> Hi all,
> Can anyone advise on installing multiple versions of
> SqlServer 2000 (ver 8) on the same server whilst
> maintaining the integrity of previous installations of
> SqlServer ?
> Thanks in advance.
> j|||Guys,
Many thanks, your comments were much appreciated.
j
>--Original Message--
>Hi all,
>Can anyone advise on installing multiple versions of
>SqlServer 2000 (ver 8) on the same server whilst
>maintaining the integrity of previous installations of
>SqlServer ?
>Thanks in advance.
>j
>.
>
Showing posts with label versions. Show all posts
Showing posts with label versions. Show all posts
Monday, March 26, 2012
Monday, March 12, 2012
Multiple database versions on same server.
We have a environment where we have one development server, one stage
and one prod. On dev and stage we need to have multiple versions of
the database to be able to do hot fixes for previous versions of the
code at the same time as we develop the new version.
Right now we just have different names for the database, for example
OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
have other databases that follows the same naming, for example
OURAPP_Security1.1 and so on. Sometimes we have to make queries
between these databases. This creates a problem because we can't
reference for example a table in the other database from a stored
procedure because the database in our production environment always
have the same name OURAPP and OURAPP_Security.
Well my question is really what the best strategy to handle this is.
My only idea is to create different instances for each version instead
and then always have the same name for the databases. Is this the
normal way to handle this? Anyone faced the same problem?On Apr 17, 12:35 pm, stuck...@.gmail.com wrote:
> We have a environment where we have one development server, one stage
> and one prod. On dev and stage we need to have multiple versions of
> the database to be able to do hot fixes for previous versions of the
> code at the same time as we develop the new version.
> Right now we just have different names for the database, for example
> OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
> have other databases that follows the same naming, for example
> OURAPP_Security1.1 and so on. Sometimes we have to make queries
> between these databases. This creates a problem because we can't
> reference for example a table in the other database from a stored
> procedure because the database in our production environment always
> have the same name OURAPP and OURAPP_Security.
> Well my question is really what the best strategy to handle this is.
> My only idea is to create different instances for each version instead
> and then always have the same name for the databases. Is this the
> normal way to handle this? Anyone faced the same problem?
You may need to change the SP with appropriate databasenames with
replace all for both dev and staging SPs.
Another option is to keep a table in dev and staging and store databse
name in that table. Write a dynamic query which picks up database name
from this table name
Caution: Dynamic Query may run slow and also prone to sql injection.
I don't think you can use synonym ( are you on SQL 2005 ?)
and one prod. On dev and stage we need to have multiple versions of
the database to be able to do hot fixes for previous versions of the
code at the same time as we develop the new version.
Right now we just have different names for the database, for example
OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
have other databases that follows the same naming, for example
OURAPP_Security1.1 and so on. Sometimes we have to make queries
between these databases. This creates a problem because we can't
reference for example a table in the other database from a stored
procedure because the database in our production environment always
have the same name OURAPP and OURAPP_Security.
Well my question is really what the best strategy to handle this is.
My only idea is to create different instances for each version instead
and then always have the same name for the databases. Is this the
normal way to handle this? Anyone faced the same problem?On Apr 17, 12:35 pm, stuck...@.gmail.com wrote:
> We have a environment where we have one development server, one stage
> and one prod. On dev and stage we need to have multiple versions of
> the database to be able to do hot fixes for previous versions of the
> code at the same time as we develop the new version.
> Right now we just have different names for the database, for example
> OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
> have other databases that follows the same naming, for example
> OURAPP_Security1.1 and so on. Sometimes we have to make queries
> between these databases. This creates a problem because we can't
> reference for example a table in the other database from a stored
> procedure because the database in our production environment always
> have the same name OURAPP and OURAPP_Security.
> Well my question is really what the best strategy to handle this is.
> My only idea is to create different instances for each version instead
> and then always have the same name for the databases. Is this the
> normal way to handle this? Anyone faced the same problem?
You may need to change the SP with appropriate databasenames with
replace all for both dev and staging SPs.
Another option is to keep a table in dev and staging and store databse
name in that table. Write a dynamic query which picks up database name
from this table name
Caution: Dynamic Query may run slow and also prone to sql injection.
I don't think you can use synonym ( are you on SQL 2005 ?)
Multiple database versions on same server.
We have a environment where we have one development server, one stage
and one prod. On dev and stage we need to have multiple versions of
the database to be able to do hot fixes for previous versions of the
code at the same time as we develop the new version.
Right now we just have different names for the database, for example
OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
have other databases that follows the same naming, for example
OURAPP_Security1.1 and so on. Sometimes we have to make queries
between these databases. This creates a problem because we can't
reference for example a table in the other database from a stored
procedure because the database in our production environment always
have the same name OURAPP and OURAPP_Security.
Well my question is really what the best strategy to handle this is.
My only idea is to create different instances for each version instead
and then always have the same name for the databases. Is this the
normal way to handle this? Anyone faced the same problem?
On Apr 17, 12:35 pm, stuck...@.gmail.com wrote:
> We have a environment where we have one development server, one stage
> and one prod. On dev and stage we need to have multiple versions of
> the database to be able to do hot fixes for previous versions of the
> code at the same time as we develop the new version.
> Right now we just have different names for the database, for example
> OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
> have other databases that follows the same naming, for example
> OURAPP_Security1.1 and so on. Sometimes we have to make queries
> between these databases. This creates a problem because we can't
> reference for example a table in the other database from a stored
> procedure because the database in our production environment always
> have the same name OURAPP and OURAPP_Security.
> Well my question is really what the best strategy to handle this is.
> My only idea is to create different instances for each version instead
> and then always have the same name for the databases. Is this the
> normal way to handle this? Anyone faced the same problem?
You may need to change the SP with appropriate databasenames with
replace all for both dev and staging SPs.
Another option is to keep a table in dev and staging and store databse
name in that table. Write a dynamic query which picks up database name
from this table name
Caution: Dynamic Query may run slow and also prone to sql injection.
I don't think you can use synonym ( are you on SQL 2005 ?)
and one prod. On dev and stage we need to have multiple versions of
the database to be able to do hot fixes for previous versions of the
code at the same time as we develop the new version.
Right now we just have different names for the database, for example
OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
have other databases that follows the same naming, for example
OURAPP_Security1.1 and so on. Sometimes we have to make queries
between these databases. This creates a problem because we can't
reference for example a table in the other database from a stored
procedure because the database in our production environment always
have the same name OURAPP and OURAPP_Security.
Well my question is really what the best strategy to handle this is.
My only idea is to create different instances for each version instead
and then always have the same name for the databases. Is this the
normal way to handle this? Anyone faced the same problem?
On Apr 17, 12:35 pm, stuck...@.gmail.com wrote:
> We have a environment where we have one development server, one stage
> and one prod. On dev and stage we need to have multiple versions of
> the database to be able to do hot fixes for previous versions of the
> code at the same time as we develop the new version.
> Right now we just have different names for the database, for example
> OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
> have other databases that follows the same naming, for example
> OURAPP_Security1.1 and so on. Sometimes we have to make queries
> between these databases. This creates a problem because we can't
> reference for example a table in the other database from a stored
> procedure because the database in our production environment always
> have the same name OURAPP and OURAPP_Security.
> Well my question is really what the best strategy to handle this is.
> My only idea is to create different instances for each version instead
> and then always have the same name for the databases. Is this the
> normal way to handle this? Anyone faced the same problem?
You may need to change the SP with appropriate databasenames with
replace all for both dev and staging SPs.
Another option is to keep a table in dev and staging and store databse
name in that table. Write a dynamic query which picks up database name
from this table name
Caution: Dynamic Query may run slow and also prone to sql injection.
I don't think you can use synonym ( are you on SQL 2005 ?)
Multiple database versions on same server.
We have a environment where we have one development server, one stage
and one prod. On dev and stage we need to have multiple versions of
the database to be able to do hot fixes for previous versions of the
code at the same time as we develop the new version.
Right now we just have different names for the database, for example
OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
have other databases that follows the same naming, for example
OURAPP_Security1.1 and so on. Sometimes we have to make queries
between these databases. This creates a problem because we can't
reference for example a table in the other database from a stored
procedure because the database in our production environment always
have the same name OURAPP and OURAPP_Security.
Well my question is really what the best strategy to handle this is.
My only idea is to create different instances for each version instead
and then always have the same name for the databases. Is this the
normal way to handle this? Anyone faced the same problem?On Apr 17, 12:35 pm, stuck...@.gmail.com wrote:
> We have a environment where we have one development server, one stage
> and one prod. On dev and stage we need to have multiple versions of
> the database to be able to do hot fixes for previous versions of the
> code at the same time as we develop the new version.
> Right now we just have different names for the database, for example
> OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
> have other databases that follows the same naming, for example
> OURAPP_Security1.1 and so on. Sometimes we have to make queries
> between these databases. This creates a problem because we can't
> reference for example a table in the other database from a stored
> procedure because the database in our production environment always
> have the same name OURAPP and OURAPP_Security.
> Well my question is really what the best strategy to handle this is.
> My only idea is to create different instances for each version instead
> and then always have the same name for the databases. Is this the
> normal way to handle this? Anyone faced the same problem?
You may need to change the SP with appropriate databasenames with
replace all for both dev and staging SPs.
Another option is to keep a table in dev and staging and store databse
name in that table. Write a dynamic query which picks up database name
from this table name
Caution: Dynamic Query may run slow and also prone to sql injection.
I don't think you can use synonym ( are you on SQL 2005 ?)
and one prod. On dev and stage we need to have multiple versions of
the database to be able to do hot fixes for previous versions of the
code at the same time as we develop the new version.
Right now we just have different names for the database, for example
OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
have other databases that follows the same naming, for example
OURAPP_Security1.1 and so on. Sometimes we have to make queries
between these databases. This creates a problem because we can't
reference for example a table in the other database from a stored
procedure because the database in our production environment always
have the same name OURAPP and OURAPP_Security.
Well my question is really what the best strategy to handle this is.
My only idea is to create different instances for each version instead
and then always have the same name for the databases. Is this the
normal way to handle this? Anyone faced the same problem?On Apr 17, 12:35 pm, stuck...@.gmail.com wrote:
> We have a environment where we have one development server, one stage
> and one prod. On dev and stage we need to have multiple versions of
> the database to be able to do hot fixes for previous versions of the
> code at the same time as we develop the new version.
> Right now we just have different names for the database, for example
> OURAPP1.1 OURAPP1.2 and so on. The problem with this is that we also
> have other databases that follows the same naming, for example
> OURAPP_Security1.1 and so on. Sometimes we have to make queries
> between these databases. This creates a problem because we can't
> reference for example a table in the other database from a stored
> procedure because the database in our production environment always
> have the same name OURAPP and OURAPP_Security.
> Well my question is really what the best strategy to handle this is.
> My only idea is to create different instances for each version instead
> and then always have the same name for the databases. Is this the
> normal way to handle this? Anyone faced the same problem?
You may need to change the SP with appropriate databasenames with
replace all for both dev and staging SPs.
Another option is to keep a table in dev and staging and store databse
name in that table. Write a dynamic query which picks up database name
from this table name
Caution: Dynamic Query may run slow and also prone to sql injection.
I don't think you can use synonym ( are you on SQL 2005 ?)
Subscribe to:
Posts (Atom)