Migrating from 2 Instances to 1 Instance (SQL 2005)

Hello, someone please help!!!!
I am trying to simplify life by combining 2 sql instances that are on the
same box into 1. Basically there is only 1 database per instance that is
being used for any real time production activity. My main problem is, that
there identical user logins (name and pw) setup on the two instances, and
when I try to combine them and call stored procs it can't find them in some
cases. In my research I found that this is because for the user, SQL really
only looks in the user's default database for the SPs. My problem with thi
s
is that I have different applications using the same login and it will be a
lot of trouble to change the user that the apps are using.
Also, it doesn't appear that the initial catalog param I am using in my
connection string is actually doing anything. Actually, I can completely
remove it and it makes no difference in how the application acts (mainly
because the connection just gets established to the default DB no matter wha
t
I pass in), any ideas on this? I mean, what is the point of having the
option if it doesn't do anything.
So, I guess my main question is, is there any way to make SQL look at more
than just the default DB to connect to, or is there a setting in SQL 2005
that allows me to connect to a different DB other than the default if I want
to by looking at the connection string.
Any help will be greatly appreciated...At the very least, have you looked at sp_change_users_login? That should
help you to consolidate servers.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
"Jeff Gibson" <Jeff Gibson@.discussions.microsoft.com> wrote in message
news:7BBD384B-A311-493B-B7F9-D66985374B2B@.microsoft.com...
Hello, someone please help!!!!
I am trying to simplify life by combining 2 sql instances that are on the
same box into 1. Basically there is only 1 database per instance that is
being used for any real time production activity. My main problem is, that
there identical user logins (name and pw) setup on the two instances, and
when I try to combine them and call stored procs it can't find them in some
cases. In my research I found that this is because for the user, SQL really
only looks in the user's default database for the SPs. My problem with
this
is that I have different applications using the same login and it will be a
lot of trouble to change the user that the apps are using.
Also, it doesn't appear that the initial catalog param I am using in my
connection string is actually doing anything. Actually, I can completely
remove it and it makes no difference in how the application acts (mainly
because the connection just gets established to the default DB no matter
what
I pass in), any ideas on this? I mean, what is the point of having the
option if it doesn't do anything.
So, I guess my main question is, is there any way to make SQL look at more
than just the default DB to connect to, or is there a setting in SQL 2005
that allows me to connect to a different DB other than the default if I want
to by looking at the connection string.
Any help will be greatly appreciated...|||Thanks for replying Tom,
As far as I know, our DBA has successfully migrated all the users, in fact,
I am having no login issues for the users themselves (since the logins are
instance based), only when the user tries to access resources that are not
located in its' default database. Basically, I have a "LoginUser" user on
two databases; say DB1, and DB2 of the same instance. If the stored
procedure is on DB2, but LoginUser's default database is DB1, I get a messag
e
from SQL saying that it couldn't find the SP. If I change the default db
using sp_defaultdb to DB2 then the call works, but this is not an option
since I do have stored procedures also on DB1 that the LoginUser is accessin
g
(well, needs to) on DB1 also. I can also use a three part naming convention
[DB2].[dbo].[StoredProcedureName], but for that to work I will n
eed to change
and re-compile all my applications - which in that case I could just add a
new user, say LoginUserDB2, and change only the applications' connection
strings that access resources on DB2 - but the problem with that is too much
up front work since I have many applications, some of which I am not even
sure where the source code is to actually change the string. Basically, I a
m
trying to find a quick and dirty way for a singe login user to access
resources on 2 databases of the same instance without changing any
application code to do so, if that is my only option I will probably just
keep the 2 instances and move on to other things.
The other weird thing is, since I am passing in the database name in my
connection string, why doesn't this signify the database to connect to. Wha
t
is the point if I can only access the default database resources?
Thanks again.
"Tom Moreau" wrote:

> At the very least, have you looked at sp_change_users_login? That should
> help you to consolidate servers.
> --
> Tom
>|||Hmm. I can't understand why it would ignore the database in the connect
string - unless somewhere in the app it's hard-coded to issue a USE
<database> command. Another explanation is that the connect string is
simply incorrect. It may not throw an error; rather it simply doesn't
switch to the specified DB and goes with the default. Can you post the
connect string (sans password)?
What method was used to migrate the logins, BTW? Have you looked at:
http://support.microsoft.com/defaul...kb;en-us;246133
http://forums.microsoft.com/MSDN/Sh...309521&SiteID=1
The scripts preserve the SID's. I'm not sure if that's what happened here.
That said, you may be able to assign default DB's to the new DB, based on
the old system, using SQL-DMO. Just step through the Logins collection of
the source server and look at the Database property. For the same Login on
the destination, set the Database property to be that of the source server.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Jeff Gibson" <JeffGibson@.discussions.microsoft.com> wrote in message
news:A1DCE3CB-AF90-47DB-A28D-AD209B3C157C@.microsoft.com...
Thanks for replying Tom,
As far as I know, our DBA has successfully migrated all the users, in fact,
I am having no login issues for the users themselves (since the logins are
instance based), only when the user tries to access resources that are not
located in its' default database. Basically, I have a "LoginUser" user on
two databases; say DB1, and DB2 of the same instance. If the stored
procedure is on DB2, but LoginUser's default database is DB1, I get a
message
from SQL saying that it couldn't find the SP. If I change the default db
using sp_defaultdb to DB2 then the call works, but this is not an option
since I do have stored procedures also on DB1 that the LoginUser is
accessing
(well, needs to) on DB1 also. I can also use a three part naming convention
[DB2].[dbo].[StoredProcedureName], but for that to work I will n
eed to
change
and re-compile all my applications - which in that case I could just add a
new user, say LoginUserDB2, and change only the applications' connection
strings that access resources on DB2 - but the problem with that is too much
up front work since I have many applications, some of which I am not even
sure where the source code is to actually change the string. Basically, I
am
trying to find a quick and dirty way for a singe login user to access
resources on 2 databases of the same instance without changing any
application code to do so, if that is my only option I will probably just
keep the 2 instances and move on to other things.
The other weird thing is, since I am passing in the database name in my
connection string, why doesn't this signify the database to connect to.
What
is the point if I can only access the default database resources?
Thanks again.
"Tom Moreau" wrote:

> At the very least, have you looked at sp_change_users_login? That should
> help you to consolidate servers.
> --
> Tom
>|||I'll reiterate - check out the sp_change_users_login. Your "identical"
user ids really aren't. They are from two different instances,
therefore have two different SIDS. unless your DBA removed all the
users and completely recreated them, they won't have access. Just
recently ran in to this, and that stored procedure saved the day.|||Hi
Tell your DBA to read this article
http://blogs.msdn.com/lcris/archive.../03/567680.aspx
"PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
news:1148583484.249905.46360@.u72g2000cwu.googlegroups.com...
> I'll reiterate - check out the sp_change_users_login. Your "identical"
> user ids really aren't. They are from two different instances,
> therefore have two different SIDS. unless your DBA removed all the
> users and completely recreated them, they won't have access. Just
> recently ran in to this, and that stored procedure saved the day.
>

migrating cluster instances to stand alone install

Hello all: looking for some general advice on proper approach. looking to move databases off of a clustered instance to a new (non-clustered) server.
Got several issues i'd like some advice on.

1. This is an OLTP instance that's been around for a while & it's pretty well encrusted with apps & processes that attach to it. Therefore it would be a very good thing if we didn't need to change the connection information in several hundred places after the move.
I've tested one approach to this that seems to work: moved the instance to a server which has the same name as the cluster resource associated with the clustered instance and an instance that has the same name as the clustered instance.
For example: cluster install is aiproddb\production, moved it to a box called aiproddb with a named instance called "production". There's a bunch of tedious network stuff that has to be done to make this work (binding an IP address to the MAC address of the new box and some murky DHCP reservation fiddling), but after the network crew got done cursing me it did finally work.
Does this seem like a reasonable approach?

2. What's the best way to transfer security info to the new instance? I used the transfer Logins DTS widget but had some problems with it not being able to find some groups in AD.

3. what's the best way to transfer DTS packages?

4. is it necessary for the new instance to be at the same patch level as the old instance? the old clustered instance is still at SP3 and i threw the latest SP4 on the new location. good/bad/indifferent?

5. i was planning on taking a full backup & restoring it to the new machine. Is there a better way? Is the wizard for copying databases a good thing?

Those are these issues i'm aware of and have given some thought to. There are probably things about this i haven't considered and would appreciate some word on.

thanks,
Garth:D 5. [...] Is the wizard for copying databases a good thing?

thanks,
Garth

NOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!!

:D

hmscott|||ok. that's one vote against the copy database wizard...|||Hello all: looking for some general advice on proper approach. looking to move databases off of a clustered instance to a new (non-clustered) server.
Got several issues i'd like some advice on.

1. This is an OLTP instance that's been around for a while & it's pretty well encrusted with apps & processes that attach to it. Therefore it would be a very good thing if we didn't need to change the connection information in several hundred places after the move.
I've tested one approach to this that seems to work: moved the instance to a server which has the same name as the cluster resource associated with the clustered instance and an instance that has the same name as the clustered instance.

I know this does not help you now, but in the future, try adding a layer of virtualization in between by using a DNS zone specific to your apps. Then you can move physical servers in and out of production smoothly without impacting application connection strings. Use one DNS A record per database (e.g. MyDB.dev.apps, MySecondDB.dev.apps and MyDB.test.apps and MySecondDB.test.apps). The apps point to the DNS name, the DNS name translates to a physical IP. When it comes time to migrate a database (or an entire server) you have one place to go to update IP addresses (the DNS server).

2. What's the best way to transfer security info to the new instance? I used the transfer Logins DTS widget but had some problems with it not being able to find some groups in AD.

Try exporting the logins to a file, cull selected logins that you don't want/need (sa comes to mind) and then inserting them with proper syntax. Somewhere there is an MS article about using BCP to do this. If I recall correctly, use "bcp log shipping sgl server logins" for your google. I also did it by copying and pasting into an Excel spreadsheet and then using formulae to build the SQL syntax. Crude, but it worked.

This will only build the logins and it will not link the users within the database to the logins (SID mismatch). For that you can use sp_change_users_login.

3. what's the best way to transfer DTS packages?

Depends on how much of your connection info is embedded. A while back I posted a script for backing up DTS packages to a structured file. If there aren't too many, this is a workable approach.

By the way, is this an upgrade to SQL 2005, or a lateral to another SQL 2000 instance? If the former, you have more work cut out for you. If the latter, you should really consider the former (ie, you should be working on an upgrade).

4. is it necessary for the new instance to be at the same patch level as the old instance? the old clustered instance is still at SP3 and i threw the latest SP4 on the new location. good/bad/indifferent?

Should be all right. Watch the AWE memory thing with SP4, but I don't remember specific issues with SP4. Be careful if you are using replication.

5. i was planning on taking a full backup & restoring it to the new machine. Is there a better way?

sp_detach and sp_attach?

The advantage with your method (if you have a large database) is that you can do a partial restore (which might take a long time) and then apply just the last log file to bring the new instance up to date to minimize your outage.

Is the wizard for copying databases a good thing?

Noooooooooooooooo!!!!!

But enough on that subject :D .

Those are these issues i'm aware of and have given some thought to. There are probably things about this i haven't considered and would appreciate some word on.

thanks,
Garth

Test, test, test, practice, practice, practice.

Good luck.

Regards,

hmscott

Migrate from user instance to native db in SQL Server Express ?

Hello,
I am currently looking at migrating a database which has been running in
"user instance" mode, onto the standard sql server express mode. Basically I
need to be able to connect to the database while it's running from other
scripts and the management studio, which I cannot do nicely while the DB is
running in user mode.
Is there any tools or good instructions on doing this?
At this point I've re-created the database from scratch and imported data,
however I am looking for a cleaner/effective way of doing this. Any
suggestions?Hi
I am not a SQLExpress expert, ut SSEUTIL will allow you to attach to a user
instance of SQL Express.
http://www.microsoft.com/downloads/...&DisplayLang=en
You could then detach (sp_detach_db) the database and re-attach
(sp_attach_db) it to the main instance of SQL Server.
You would need to change the connection string in the application that
creates the user instance to reference the main instance of SQL Server and
not create the user instance.
John
"NSiggel" wrote:

> Hello,
> I am currently looking at migrating a database which has been running in
> "user instance" mode, onto the standard sql server express mode. Basically
I
> need to be able to connect to the database while it's running from other
> scripts and the management studio, which I cannot do nicely while the DB i
s
> running in user mode.
> Is there any tools or good instructions on doing this?
> At this point I've re-created the database from scratch and imported data,
> however I am looking for a cleaner/effective way of doing this. Any
> suggestions?
>sql

Migrate from user instance to native db in SQL Server Express ?

Hello,
I am currently looking at migrating a database which has been running in
"user instance" mode, onto the standard sql server express mode. Basically I
need to be able to connect to the database while it's running from other
scripts and the management studio, which I cannot do nicely while the DB is
running in user mode.
Is there any tools or good instructions on doing this?
At this point I've re-created the database from scratch and imported data,
however I am looking for a cleaner/effective way of doing this. Any
suggestions?
Hi
I am not a SQLExpress expert, ut SSEUTIL will allow you to attach to a user
instance of SQL Express.
http://www.microsoft.com/downloads/details.aspx?FamilyID=fa87e828-173f-472e-a85c-27ed01cf6b02&DisplayLang=en
You could then detach (sp_detach_db) the database and re-attach
(sp_attach_db) it to the main instance of SQL Server.
You would need to change the connection string in the application that
creates the user instance to reference the main instance of SQL Server and
not create the user instance.
John
"NSiggel" wrote:

> Hello,
> I am currently looking at migrating a database which has been running in
> "user instance" mode, onto the standard sql server express mode. Basically I
> need to be able to connect to the database while it's running from other
> scripts and the management studio, which I cannot do nicely while the DB is
> running in user mode.
> Is there any tools or good instructions on doing this?
> At this point I've re-created the database from scratch and imported data,
> however I am looking for a cleaner/effective way of doing this. Any
> suggestions?
>

Migrate from user instance to native db in SQL Server Express ?

Hello,
I am currently looking at migrating a database which has been running in
"user instance" mode, onto the standard sql server express mode. Basically I
need to be able to connect to the database while it's running from other
scripts and the management studio, which I cannot do nicely while the DB is
running in user mode.
Is there any tools or good instructions on doing this?
At this point I've re-created the database from scratch and imported data,
however I am looking for a cleaner/effective way of doing this. Any
suggestions?Hi
I am not a SQLExpress expert, ut SSEUTIL will allow you to attach to a user
instance of SQL Express.
http://www.microsoft.com/downloads/details.aspx?FamilyID=fa87e828-173f-472e-a85c-27ed01cf6b02&DisplayLang=en
You could then detach (sp_detach_db) the database and re-attach
(sp_attach_db) it to the main instance of SQL Server.
You would need to change the connection string in the application that
creates the user instance to reference the main instance of SQL Server and
not create the user instance.
John
"NSiggel" wrote:
> Hello,
> I am currently looking at migrating a database which has been running in
> "user instance" mode, onto the standard sql server express mode. Basically I
> need to be able to connect to the database while it's running from other
> scripts and the management studio, which I cannot do nicely while the DB is
> running in user mode.
> Is there any tools or good instructions on doing this?
> At this point I've re-created the database from scratch and imported data,
> however I am looking for a cleaner/effective way of doing this. Any
> suggestions?
>

Migrate from Single-Server to Cluster

I have a SharePoint installation that currently uses a single SQL Server and
connects to the default instance. I want to migrate to a cluster without
doing a full backup/move/restore. I'm thinking if I set up the cluster with
the same name as the current SQL server it should be transparent to
SharePoint. Has anyone tried this?
This is not a good idea, not even a great one. SPS can get picky. I would
due a true migration, with a tested backup/restore, then move the DB's.
Cheers,
Rodney R. Fournier
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://www.msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
ClusterHelp.com is a Microsoft Certified Gold Partner
"Milan Gross" <MilanGross@.discussions.microsoft.com> wrote in message
news:19F19F3B-7721-4301-9303-B7ECF518B4A2@.microsoft.com...
>I have a SharePoint installation that currently uses a single SQL Server
>and
> connects to the default instance. I want to migrate to a cluster without
> doing a full backup/move/restore. I'm thinking if I set up the cluster
> with
> the same name as the current SQL server it should be transparent to
> SharePoint. Has anyone tried this?

Migrate form stand alone to clustered server

Here is the scenario:
We have an existing production non clustered SQL 2000 server instance that we need to migrate to a new clustered SQL 2000 server instance. We need to accomplish this without affecting the FQDN that applications use to call this server. I found this article on a solution to rename the server after an xcopy of the entire db structure. Here is the link http://vyaskn.tripod.com/moving_sql_server.htm. The other issue that we are trying to resolve is the time it takes for the snapshots of replication to run (in our case almost a full day). That is why this approach looked like it may be a good solution for us.

Here is the question:
Is it possible to move our existing database to a new clustered environment without having to change the FQDN that other applications use to access this database and without having to reinitialize replication?GrantAsh,

The link you posted could work. But, the problem is in the drive letters and the folders.

The problem is that for a clustered server the data drives need to be shared in the cluster. The concern that I would have is the drive letters that you used for your current SQL server would not match the Clustered SQL server drives.

But, if you can match the drive letters then copying the data is not a problem.

But I can't stress this enough, using the method described on that web page to change the SQL server name will not work for a Clustered SQL Server.

I would suggest reading the following:
http://support.microsoft.com/kb/244980/
http://www.sql-server-performance.com/clustering_2000.asp

bEH

Migrate existing standalone to cluster

While away on vacation my company had some software installed that required a
new instance of SQL Server 2K to be created on our existing active/passive
cluster.
Because the techs doing the install did not know the password for our domain
cluster user account they created the standalone instance on the db server.
What I need to know is how do I go about migrating it to a clustered instance
instead of a standalone so as to take advantage of the failover capabilities?
i.e. I already have a clustered server with one clustered instance. They
installed a standalone instance alongside and now I need to migrate the new
instance to another named clustered instance.
Is it possible to go with the existing clustered instance and simply move
the DB's to the cluster? What's driving the need for two instances?
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
While away on vacation my company had some software installed that required
a
new instance of SQL Server 2K to be created on our existing active/passive
cluster.
Because the techs doing the install did not know the password for our domain
cluster user account they created the standalone instance on the db server.
What I need to know is how do I go about migrating it to a clustered
instance
instead of a standalone so as to take advantage of the failover
capabilities?
i.e. I already have a clustered server with one clustered instance. They
installed a standalone instance alongside and now I need to migrate the new
instance to another named clustered instance.
|||Oh you'll love this...
The software we purchased for our new document management system *cough*
Documentum *cough*, is designed so as to require a case-sensitive database.
I know...D-U-M Dum...And because all of our other databases are NOT
case-sensitive (and there's no way in h*ll I would change that) we had to
create a new instance that was.
"Tom Moreau" wrote:

> Is it possible to go with the existing clustered instance and simply move
> the DB's to the cluster? What's driving the need for two instances?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
> While away on vacation my company had some software installed that required
> a
> new instance of SQL Server 2K to be created on our existing active/passive
> cluster.
> Because the techs doing the install did not know the password for our domain
> cluster user account they created the standalone instance on the db server.
> What I need to know is how do I go about migrating it to a clustered
> instance
> instead of a standalone so as to take advantage of the failover
> capabilities?
> i.e. I already have a clustered server with one clustered instance. They
> installed a standalone instance alongside and now I need to migrate the new
> instance to another named clustered instance.
>
|||That's not justification enough. You can create a case-sensitive database
within an instance that is not case sensitive.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
Oh you'll love this...
The software we purchased for our new document management system *cough*
Documentum *cough*, is designed so as to require a case-sensitive database.
I know...D-U-M Dum...And because all of our other databases are NOT
case-sensitive (and there's no way in h*ll I would change that) we had to
create a new instance that was.
"Tom Moreau" wrote:

> Is it possible to go with the existing clustered instance and simply move
> the DB's to the cluster? What's driving the need for two instances?
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:F9743B37-FC4D-4909-A4CA-608078BB5A3E@.microsoft.com...
> While away on vacation my company had some software installed that
> required
> a
> new instance of SQL Server 2K to be created on our existing active/passive
> cluster.
> Because the techs doing the install did not know the password for our
> domain
> cluster user account they created the standalone instance on the db
> server.
> What I need to know is how do I go about migrating it to a clustered
> instance
> instead of a standalone so as to take advantage of the failover
> capabilities?
> i.e. I already have a clustered server with one clustered instance. They
> installed a standalone instance alongside and now I need to migrate the
> new
> instance to another named clustered instance.
>
|||Not that it will matter much anyway, since it is already installed, but how
do you go about making a case-sensitive db inside of an insensitive instance?
And I still need to know how to change the standalone to a clustered...
"Tom Moreau" wrote:

> That's not justification enough. You can create a case-sensitive database
> within an instance that is not case sensitive.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
> Oh you'll love this...
> The software we purchased for our new document management system *cough*
> Documentum *cough*, is designed so as to require a case-sensitive database.
> I know...D-U-M Dum...And because all of our other databases are NOT
> case-sensitive (and there's no way in h*ll I would change that) we had to
> create a new instance that was.
> "Tom Moreau" wrote:
>
>
|||To create a database with a case-sensitive collation, just use the COLLATE
option:
create database MyDB
collate Latin1_General_CS_AI
As for the other bit, you'll have to create the new virtual server (and
named instance) in the same manner as you created the other virtual server
and instance. However, you can specify the collation for the new instance
at that time. Once that's done, then backup and restore the DB's from the
standalone to the new instance. Finally, remove the standalone.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...
Not that it will matter much anyway, since it is already installed, but how
do you go about making a case-sensitive db inside of an insensitive
instance?
And I still need to know how to change the standalone to a clustered...
"Tom Moreau" wrote:

> That's not justification enough. You can create a case-sensitive database
> within an instance that is not case sensitive.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:A8F1525E-3D96-4842-AFBD-87160EC34CB8@.microsoft.com...
> Oh you'll love this...
> The software we purchased for our new document management system *cough*
> Documentum *cough*, is designed so as to require a case-sensitive
> database.
> I know...D-U-M Dum...And because all of our other databases are NOT
> case-sensitive (and there's no way in h*ll I would change that) we had to
> create a new instance that was.
> "Tom Moreau" wrote:
>
>
|||Creating a database in an instance with a collation that is differnt than
the default server collation, as Tom suggested, is certainly one approach
you can explore. If everything is under your control, you can make this
work. A vendor package like Ducumentum, however, may crap out becasue of the
likely collation conflict with the tempdb database. So test it out!
Linchi
"Cary" <Cary@.discussions.microsoft.com> wrote in message
news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...[vbcol=seagreen]
> Not that it will matter much anyway, since it is already installed, but
> how
> do you go about making a case-sensitive db inside of an insensitive
> instance?
> And I still need to know how to change the standalone to a clustered...
>
> "Tom Moreau" wrote:
|||Question regarding what Linchi wrote about the temp DB being an issue. We
are currently in the same situation with a mulitnode cluster that will house
a peoplesoft instance (different collation than the other instances) but have
concerns on how failover will happen with this different collation instance
vs the collation instances that are indentical. Will failover happen just as
if all the collations were the same or do we have to take special precautions?
"Linchi Shea" wrote:

> Creating a database in an instance with a collation that is differnt than
> the default server collation, as Tom suggested, is certainly one approach
> you can explore. If everything is under your control, you can make this
> work. A vendor package like Ducumentum, however, may crap out becasue of the
> likely collation conflict with the tempdb database. So test it out!
> Linchi
> "Cary" <Cary@.discussions.microsoft.com> wrote in message
> news:FBFC5A77-4A41-4B6E-B076-370E9111321B@.microsoft.com...
>
>
|||Multiple collations are no different on a cluster than on a stand-alone box.
Failover will work exactly the same regardless of the system or anyuser
database collation. Collations have been separated from the system code
page since SQL 7.0
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Todd" <Todd@.discussions.microsoft.com> wrote in message
news:32F54FD8-2882-4125-8202-D6CE442C83E5@.microsoft.com...[vbcol=seagreen]
> Question regarding what Linchi wrote about the temp DB being an issue. We
> are currently in the same situation with a mulitnode cluster that will
> house
> a peoplesoft instance (different collation than the other instances) but
> have
> concerns on how failover will happen with this different collation
> instance
> vs the collation instances that are indentical. Will failover happen just
> as
> if all the collations were the same or do we have to take special
> precautions?
> "Linchi Shea" wrote:

Microsoft SQL Web Data Administrator

I have installed this and I cannot access my MSDE Instance. Any ideas?
The instance of my DB is running.
My Server Manager Says that it is running, Services says that it is running,
but I cannot get to the SQLServer (On my own pc) with the Web Data
Administrator or TOAD for SQL Server.
|||It is quite possible that it is running on a non-standard port not 1433.
Open up a console window and type following
PROMPT> telnet localhost 1433
if you see a blank screen that means the server is listening. If you get
an error that means that it is listening on a different port
Joe Tobey wrote:
> I have installed this and I cannot access my MSDE Instance. Any ideas?
> The instance of my DB is running.
|||It is listen in on a different PORT...how do I change that?
"Dennis Black" wrote:

> It is quite possible that it is running on a non-standard port not 1433.
> Open up a console window and type following
> PROMPT> telnet localhost 1433
> if you see a blank screen that means the server is listening. If you get
> an error that means that it is listening on a different port
>
> Joe Tobey wrote:
>
>
|||To determine the port MSDE is using, run the SQL Server Network Utility
on the machine hosting the MSDE instance. The SQL Server Network
Utility can be found at \Program Files\Microsoft SQL
Server\80\Tools\Binn\svrnetcn.exe.
On the general tab, select the your MSDE instance. Select TCP/IP and
press the Properties button and look at the port
Dennis
Joe Tobey wrote:[vbcol=seagreen]
> It is listen in on a different PORT...how do I change that?
> "Dennis Black" wrote:
>

Microsoft SQL Server, Error: 87 17march

Source computer: SQL server 2005 SP1
Remote computer : SQLEXPRESS
When I try to register/connect with remote server (named instance) using sql
server management studio I am getting following error:
TITLE: New Server Registration
--
Testing the registered server failed. Verify the server name, login
credentials, and database, and then click Test again.
--
ADDITIONAL INFORMATION:
An error has occurred while establishing a connection to the server. When
connecting to SQL Server 2005, this failure may be caused by the fact that
under the default settings SQL Server does not allow remote connections.
(provider: SQL Network Interfaces, error: 25 - Connection string is not
valid) (Microsoft SQL Server, Error: 87)
Thanks
Ontario, canadaSource computer: SQL server 2005 SP1 (Microsoft windows nt 5.1)
Remote computer : Microsoft SQL server express edition (Microsoft windows
nt 5.1)
-
ontario, canada
"db" wrote:
> Source computer: SQL server 2005 SP1
> Remote computer : SQLEXPRESS
>
> When I try to register/connect with remote server (named instance) using sql
> server management studio I am getting following error:
> TITLE: New Server Registration
> --
> Testing the registered server failed. Verify the server name, login
> credentials, and database, and then click Test again.
> --
> ADDITIONAL INFORMATION:
> An error has occurred while establishing a connection to the server. When
> connecting to SQL Server 2005, this failure may be caused by the fact that
> under the default settings SQL Server does not allow remote connections.
> (provider: SQL Network Interfaces, error: 25 - Connection string is not
> valid) (Microsoft SQL Server, Error: 87)
>
> Thanks
> Ontario, canada

Microsoft SQL Server, Error: 87 17march

Source computer: SQL server 2005 SP1
Remote computer : SQLEXPRESS
When I try to register/connect with remote server (named instance) using sql
server management studio I am getting following error:
TITLE: New Server Registration
Testing the registered server failed. Verify the server name, login
credentials, and database, and then click Test again.
ADDITIONAL INFORMATION:
An error has occurred while establishing a connection to the server. When
connecting to SQL Server 2005, this failure may be caused by the fact that
under the default settings SQL Server does not allow remote connections.
(provider: SQL Network Interfaces, error: 25 - Connection string is not
valid) (Microsoft SQL Server, Error: 87)
Thanks
Ontario, canada
Source computer: SQL server 2005 SP1 (Microsoft windows nt 5.1)
Remote computer : Microsoft SQL server express edition (Microsoft windows
nt 5.1)
-
ontario, canada
"db" wrote:

> Source computer: SQL server 2005 SP1
> Remote computer : SQLEXPRESS
>
> When I try to register/connect with remote server (named instance) using sql
> server management studio I am getting following error:
> TITLE: New Server Registration
> --
> Testing the registered server failed. Verify the server name, login
> credentials, and database, and then click Test again.
> --
> ADDITIONAL INFORMATION:
> An error has occurred while establishing a connection to the server. When
> connecting to SQL Server 2005, this failure may be caused by the fact that
> under the default settings SQL Server does not allow remote connections.
> (provider: SQL Network Interfaces, error: 25 - Connection string is not
> valid) (Microsoft SQL Server, Error: 87)
>
> Thanks
> Ontario, canada