a database restore technique question...

background sql2k on nt4.
one of the disk stripe went bad during the weekend and our network admin
rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
installed origionally. his restore is like this:
1. origional sql excutables and database files are located at d:\mssql\, he
renamed it to d:\mssql_x\
2. he reinstalled sql2k and system databases to d:\mssql\, after that he was
able to start the sql service again.
3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back to
d:\mssql\
but the sql service wouldn't start. he said that tenique worked a couple of
times at other occasions.
my questions:
1. what might go wrong this time?
2. what's wrong with this technique, there is no backup or restore involved.
almost sounds too easy to be true.
thank you.
What he should have done was copy over the old database files to the new
folder. It appears that perhaps the old executables got corrupted.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Steve Lin" <lins@.nospam.portptld.com> wrote in message
news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
background sql2k on nt4.
one of the disk stripe went bad during the weekend and our network admin
rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
installed origionally. his restore is like this:
1. origional sql excutables and database files are located at d:\mssql\, he
renamed it to d:\mssql_x\
2. he reinstalled sql2k and system databases to d:\mssql\, after that he was
able to start the sql service again.
3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back to
d:\mssql\
but the sql service wouldn't start. he said that tenique worked a couple of
times at other occasions.
my questions:
1. what might go wrong this time?
2. what's wrong with this technique, there is no backup or restore involved.
almost sounds too easy to be true.
thank you.
|||"...copy over the old database files to the new..."
does that include system files such as master, msdb and so on?
if that's the case, wouldn't you need to 'attach' all the databases?
his tenique simple renamed the original directory to the new directory.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#cXyfpiJEHA.2412@.TK2MSFTNGP12.phx.gbl...
> What he should have done was copy over the old database files to the new
> folder. It appears that perhaps the old executables got corrupted.
> --
> Tom
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com/sql
>
> "Steve Lin" <lins@.nospam.portptld.com> wrote in message
> news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
> background sql2k on nt4.
> one of the disk stripe went bad during the weekend and our network admin
> rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
> installed origionally. his restore is like this:
> 1. origional sql excutables and database files are located at d:\mssql\,
he
> renamed it to d:\mssql_x\
> 2. he reinstalled sql2k and system databases to d:\mssql\, after that he
was
> able to start the sql service again.
> 3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back
to
> d:\mssql\
> but the sql service wouldn't start. he said that tenique worked a couple
of
> times at other occasions.
> my questions:
> 1. what might go wrong this time?
> 2. what's wrong with this technique, there is no backup or restore
involved.
> almost sounds too easy to be true.
> thank you.
>
|||For everything to be in synch, then yes, you would have to move all
databases - assuming none were corrupted. Simply renaming the directory
would make it point to all of the old stuff - including the executables. If
the original SQL Server had been shut down properly, you wouldn't need to
attach anything.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Steve Lin" <lins@.nospam.portptld.com> wrote in message
news:OsUOquiJEHA.228@.TK2MSFTNGP10.phx.gbl...
"...copy over the old database files to the new..."
does that include system files such as master, msdb and so on?
if that's the case, wouldn't you need to 'attach' all the databases?
his tenique simple renamed the original directory to the new directory.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#cXyfpiJEHA.2412@.TK2MSFTNGP12.phx.gbl...
> What he should have done was copy over the old database files to the new
> folder. It appears that perhaps the old executables got corrupted.
> --
> Tom
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com/sql
>
> "Steve Lin" <lins@.nospam.portptld.com> wrote in message
> news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
> background sql2k on nt4.
> one of the disk stripe went bad during the weekend and our network admin
> rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
> installed origionally. his restore is like this:
> 1. origional sql excutables and database files are located at d:\mssql\,
he
> renamed it to d:\mssql_x\
> 2. he reinstalled sql2k and system databases to d:\mssql\, after that he
was
> able to start the sql service again.
> 3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back
to
> d:\mssql\
> but the sql service wouldn't start. he said that tenique worked a couple
of
> times at other occasions.
> my questions:
> 1. what might go wrong this time?
> 2. what's wrong with this technique, there is no backup or restore
involved.
> almost sounds too easy to be true.
> thank you.
>

a database restore technique question...

background sql2k on nt4.
one of the disk stripe went bad during the weekend and our network admin
rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
installed origionally. his restore is like this:
1. origional sql excutables and database files are located at d:\mssql\, he
renamed it to d:\mssql_x\
2. he reinstalled sql2k and system databases to d:\mssql\, after that he was
able to start the sql service again.
3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back to
d:\mssql\
but the sql service wouldn't start. he said that tenique worked a couple of
times at other occasions.
my questions:
1. what might go wrong this time?
2. what's wrong with this technique, there is no backup or restore involved.
almost sounds too easy to be true.
thank you.What he should have done was copy over the old database files to the new
folder. It appears that perhaps the old executables got corrupted.
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Steve Lin" <lins@.nospam.portptld.com> wrote in message
news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
background sql2k on nt4.
one of the disk stripe went bad during the weekend and our network admin
rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
installed origionally. his restore is like this:
1. origional sql excutables and database files are located at d:\mssql\, he
renamed it to d:\mssql_x\
2. he reinstalled sql2k and system databases to d:\mssql\, after that he was
able to start the sql service again.
3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back to
d:\mssql\
but the sql service wouldn't start. he said that tenique worked a couple of
times at other occasions.
my questions:
1. what might go wrong this time?
2. what's wrong with this technique, there is no backup or restore involved.
almost sounds too easy to be true.
thank you.|||"...copy over the old database files to the new..."
does that include system files such as master, msdb and so on?
if that's the case, wouldn't you need to 'attach' all the databases?
his tenique simple renamed the original directory to the new directory.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#cXyfpiJEHA.2412@.TK2MSFTNGP12.phx.gbl...
> What he should have done was copy over the old database files to the new
> folder. It appears that perhaps the old executables got corrupted.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com/sql
>
> "Steve Lin" <lins@.nospam.portptld.com> wrote in message
> news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
> background sql2k on nt4.
> one of the disk stripe went bad during the weekend and our network admin
> rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
> installed origionally. his restore is like this:
> 1. origional sql excutables and database files are located at d:\mssql\,
he
> renamed it to d:\mssql_x\
> 2. he reinstalled sql2k and system databases to d:\mssql\, after that he
was
> able to start the sql service again.
> 3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back
to
> d:\mssql\
> but the sql service wouldn't start. he said that tenique worked a couple
of
> times at other occasions.
> my questions:
> 1. what might go wrong this time?
> 2. what's wrong with this technique, there is no backup or restore
involved.
> almost sounds too easy to be true.
> thank you.
>|||For everything to be in synch, then yes, you would have to move all
databases - assuming none were corrupted. Simply renaming the directory
would make it point to all of the old stuff - including the executables. If
the original SQL Server had been shut down properly, you wouldn't need to
attach anything.
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Steve Lin" <lins@.nospam.portptld.com> wrote in message
news:OsUOquiJEHA.228@.TK2MSFTNGP10.phx.gbl...
"...copy over the old database files to the new..."
does that include system files such as master, msdb and so on?
if that's the case, wouldn't you need to 'attach' all the databases?
his tenique simple renamed the original directory to the new directory.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#cXyfpiJEHA.2412@.TK2MSFTNGP12.phx.gbl...
> What he should have done was copy over the old database files to the new
> folder. It appears that perhaps the old executables got corrupted.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com/sql
>
> "Steve Lin" <lins@.nospam.portptld.com> wrote in message
> news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
> background sql2k on nt4.
> one of the disk stripe went bad during the weekend and our network admin
> rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
> installed origionally. his restore is like this:
> 1. origional sql excutables and database files are located at d:\mssql\,
he
> renamed it to d:\mssql_x\
> 2. he reinstalled sql2k and system databases to d:\mssql\, after that he
was
> able to start the sql service again.
> 3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back
to
> d:\mssql\
> but the sql service wouldn't start. he said that tenique worked a couple
of
> times at other occasions.
> my questions:
> 1. what might go wrong this time?
> 2. what's wrong with this technique, there is no backup or restore
involved.
> almost sounds too easy to be true.
> thank you.
>

a database restore technique question...

background sql2k on nt4.
one of the disk stripe went bad during the weekend and our network admin
rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
installed origionally. his restore is like this:
1. origional sql excutables and database files are located at d:\mssql\, he
renamed it to d:\mssql_x\
2. he reinstalled sql2k and system databases to d:\mssql\, after that he was
able to start the sql service again.
3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back to
d:\mssql\
but the sql service wouldn't start. he said that tenique worked a couple of
times at other occasions.
my questions:
1. what might go wrong this time?
2. what's wrong with this technique, there is no backup or restore involved.
almost sounds too easy to be true.
thank you.What he should have done was copy over the old database files to the new
folder. It appears that perhaps the old executables got corrupted.
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Steve Lin" <lins@.nospam.portptld.com> wrote in message
news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
background sql2k on nt4.
one of the disk stripe went bad during the weekend and our network admin
rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
installed origionally. his restore is like this:
1. origional sql excutables and database files are located at d:\mssql\, he
renamed it to d:\mssql_x\
2. he reinstalled sql2k and system databases to d:\mssql\, after that he was
able to start the sql service again.
3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back to
d:\mssql\
but the sql service wouldn't start. he said that tenique worked a couple of
times at other occasions.
my questions:
1. what might go wrong this time?
2. what's wrong with this technique, there is no backup or restore involved.
almost sounds too easy to be true.
thank you.|||"...copy over the old database files to the new..."
does that include system files such as master, msdb and so on?
if that's the case, wouldn't you need to 'attach' all the databases?
his tenique simple renamed the original directory to the new directory.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#cXyfpiJEHA.2412@.TK2MSFTNGP12.phx.gbl...
> What he should have done was copy over the old database files to the new
> folder. It appears that perhaps the old executables got corrupted.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com/sql
>
> "Steve Lin" <lins@.nospam.portptld.com> wrote in message
> news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
> background sql2k on nt4.
> one of the disk stripe went bad during the weekend and our network admin
> rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
> installed origionally. his restore is like this:
> 1. origional sql excutables and database files are located at d:\mssql\,
he
> renamed it to d:\mssql_x\
> 2. he reinstalled sql2k and system databases to d:\mssql\, after that he
was
> able to start the sql service again.
> 3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back
to
> d:\mssql\
> but the sql service wouldn't start. he said that tenique worked a couple
of
> times at other occasions.
> my questions:
> 1. what might go wrong this time?
> 2. what's wrong with this technique, there is no backup or restore
involved.
> almost sounds too easy to be true.
> thank you.
>|||For everything to be in synch, then yes, you would have to move all
databases - assuming none were corrupted. Simply renaming the directory
would make it point to all of the old stuff - including the executables. If
the original SQL Server had been shut down properly, you wouldn't need to
attach anything.
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Steve Lin" <lins@.nospam.portptld.com> wrote in message
news:OsUOquiJEHA.228@.TK2MSFTNGP10.phx.gbl...
"...copy over the old database files to the new..."
does that include system files such as master, msdb and so on?
if that's the case, wouldn't you need to 'attach' all the databases?
his tenique simple renamed the original directory to the new directory.
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#cXyfpiJEHA.2412@.TK2MSFTNGP12.phx.gbl...
> What he should have done was copy over the old database files to the new
> folder. It appears that perhaps the old executables got corrupted.
> --
> Tom
> ---
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinnaclepublishing.com/sql
>
> "Steve Lin" <lins@.nospam.portptld.com> wrote in message
> news:%234$J1ViJEHA.1392@.TK2MSFTNGP09.phx.gbl...
> background sql2k on nt4.
> one of the disk stripe went bad during the weekend and our network admin
> rebuilt the box and reinstalled sql2k w/ sp2 but he didnt' check what was
> installed origionally. his restore is like this:
> 1. origional sql excutables and database files are located at d:\mssql\,
he
> renamed it to d:\mssql_x\
> 2. he reinstalled sql2k and system databases to d:\mssql\, after that he
was
> able to start the sql service again.
> 3. he then renamed d:\mssql\ to d:\mssql_y\, and renamed d:\mssql_x\ back
to
> d:\mssql\
> but the sql service wouldn't start. he said that tenique worked a couple
of
> times at other occasions.
> my questions:
> 1. what might go wrong this time?
> 2. what's wrong with this technique, there is no backup or restore
involved.
> almost sounds too easy to be true.
> thank you.
>

A couple of questions on Remote connection to SQL Server 2005 database

I have a SQL Server 2005 database (called BDHSE) in a PC which i call PC1. I have a second PC (PC2) and both are within a network (a WLAN).

What i want is to have access to BDHSE from an application in VB6 (APP1) running in PC2. All the INSERT, DELETE, UPDATE records process is done through APP1.

APP1 ia currently running in PC1 and is to be installed on PC2.

I have these questions:

1. What do i need to install in PC2 since all the INSERT, DELETE, and UPDATE is done using APP1? I guess i only have to install the Microsoft SQL Native Client (with all the prerequisites of course) but i am not sure.

2. In the APP1 made in VB6, do i have to change the connectionstring since i am accesing the database which physically is at PC1 and the APP1 will be used in PC2?

3. Any advice you can give me on doing this will be well received.

Thanks in advance,

BSc Fernando Martinez

1. If you do not want to use any new features of the SQL Server 2k5, you can also install the MDAC stack. You don′t need to install the SNAC drivers. If you install the SNAC drivers and want to use them, make sure that you change your connectionstring (samles can be found on the site www.connectionstrings.com).

2. I don′t get your throught here, but you will have to point the connectionstring of the application to the server where the database is actually hosted.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||thanks, i found out the problem.

A connection could not be established...Cannot open user default database...

Hello,
I'm running SQL7 on a Win2K server. I was in the midst of
restoring a database when I lost connectivity to the
network and the job failed.
Now if I try to view the database within Enterprise
Manager, I get the following error:
---
A connection could not be established to <servername>.
Cannot open user default database '<ID>. Using master
database instead. Please varify SQL Server is running and
check your SQL Server registration properties (by right-
clicking on the <servername> node) and try again.
---
I checked and SQL is running and the registration
properties are correct.
Any help would be appreciated.Seems like the database is "lost", as you terminated the restore, and the
logins that your EM registration login is using has that database as the
default database. I suggest you login using ISQL.EXE and change default
database using sp_defaultdb.
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Jimbo" <anonymous@.discussions.microsoft.com> wrote in message
news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
> Hello,
> I'm running SQL7 on a Win2K server. I was in the midst of
> restoring a database when I lost connectivity to the
> network and the job failed.
> Now if I try to view the database within Enterprise
> Manager, I get the following error:
> ---
> A connection could not be established to <servername>.
> Cannot open user default database '<ID>. Using master
> database instead. Please varify SQL Server is running and
> check your SQL Server registration properties (by right-
> clicking on the <servername> node) and try again.
> ---
> I checked and SQL is running and the registration
> properties are correct.
> Any help would be appreciated.
>|||Thanks Tibor - I tried that as outlined in MS KB 196076,
but I still get a the same error.(?)
>--Original Message--
>Seems like the database is "lost", as you terminated the
restore, and the
>logins that your EM registration login is using has that
database as the
>default database. I suggest you login using ISQL.EXE and
change default
>database using sp_defaultdb.
>--
>Tibor Karaszi, SQL Server MVP
>Archive at:
>http://groups.google.com/groups?
oi=djq&as_ugroup=microsoft.public.sqlserver
>
>"Jimbo" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0c6201c3df7b$ee9a7fe0$a101280a@.phx.gbl...
>> Hello,
>> I'm running SQL7 on a Win2K server. I was in the midst
of
>> restoring a database when I lost connectivity to the
>> network and the job failed.
>> Now if I try to view the database within Enterprise
>> Manager, I get the following error:
>> ---
>> A connection could not be established to <servername>.
>> Cannot open user default database '<ID>. Using master
>> database instead. Please varify SQL Server is running
and
>> check your SQL Server registration properties (by right-
>> clicking on the <servername> node) and try again.
>> ---
>> I checked and SQL is running and the registration
>> properties are correct.
>> Any help would be appreciated.
>>
>
>.
>|||Tibor Karaszi wrote:
> Seems like the database is "lost", as you terminated the restore, and the
> logins that your EM registration login is using has that database as the
> default database. I suggest you login using ISQL.EXE and change default
> database using sp_defaultdb.
>
Thanks for the information. That seems to have fixed the lost db server
issue in the drop down. Still can't get the damn app server to
connect to the db server though. Will keep searching.|||> Thanks for the information. That seems to have fixed the lost db server
> issue in the drop down. Still can't get the damn app server to connect
> to the db server though. Will keep searching.
Everyone may ignore my last post.

A connection could not be established between networks

While trying to connect SQL server from one network to another I'm suddenly
getting this error message:
A connection could not be established to ServerName.
Reason: Login failed for user '(null)'. Reason: Not associated with a
trusted SQL Server connection..
Please verify SQL Server is running and check your SQL Server registration
properties...
Windows authentication validates. Different logins are used for both
servers, but SQL Server is set to startup using the same login and password.
This login is given administrator rights on both servers.
?
"Steven" <Steven@.discussions.microsoft.com> wrote in message
news:DD3A83A2-71C0-4030-A92A-C7A02BF85AF4@.microsoft.com...
> While trying to connect SQL server from one network to another I'm
suddenly
> getting this error message:
> A connection could not be established to ServerName.
> Reason: Login failed for user '(null)'. Reason: Not associated with a
> trusted SQL Server connection..
That usually means that the user account could not be translated into an SQL
Server login account. Perhaps because the domain\user account does not have
access to the server running SQL Server.

> Please verify SQL Server is running and check your SQL Server registration
> properties...
> Windows authentication validates. Different logins are used for both
> servers, but SQL Server is set to startup using the same login and
password.
> This login is given administrator rights on both servers.
> ?
I'm confused by the last 2 sentences. Are these servers in a domain,
workgroup or simply standalone servers?
Steve
|||There are actually 3 servers: A, B, & C. Server A is in workgroup 1 and
cannot connect to servers B or C. Server B is in workgroup 2 and cannot
connect to server A, but can connect to server C. Server C is in a domain
and connects to server B, but not server A.
Important notes: Servers A runs under the NT login of Admin with a password
of AdminPW1. Servers B and C run under the NT login of Admin with a password
of AdminPW2. All three servers use the start up account of user SQLAdmin
with a password of SQLAdminPW and all three servers are set to use Windows
and SQL Server authentication.
Also, replication is working between servers A and B and between servers A
and C. It's the Ent Man that's not able to connect.
"Steve Thompson" wrote:

> "Steven" <Steven@.discussions.microsoft.com> wrote in message
> news:DD3A83A2-71C0-4030-A92A-C7A02BF85AF4@.microsoft.com...
> suddenly
> That usually means that the user account could not be translated into an SQL
> Server login account. Perhaps because the domain\user account does not have
> access to the server running SQL Server.
> password.
> I'm confused by the last 2 sentences. Are these servers in a domain,
> workgroup or simply standalone servers?
> Steve
>
>