Named instance, no default instance -> connection problems?

Hey,
I have the following problem with deployment of MSDE. Here's what I want
to do:
- I want to install MSDE in a named instance, even if it wasn't installed
before.
- I want to connect to the local server only, if possible with a
"generic" name, so I don't have to look up the system name
and stuff.
I can't really get this to work at all. I have connection strings that
work fine on development machines (where the default instance name is
used), using . for the server name. On the test machine, using
..\MYINSTANCE doesn't work at all. I read suggestions to use
(local)\MYINSTANCE instead of .\MYINSTANCE, but to no avail.
The funny thing is, even SYSTEMNAME\MYINSTANCE doesn't work unless there's
a default instance running on the same machine. Plus, it seems cumbersome
to have to find out the system's name for such a purpose.
Maybe I'm just seriously wrong about something... I didn't think it would
be that hard to set up a local (!, no networking enabled) database server
using the standard (!, they do say I'm to use a vendor-specific instance,
don't they?) setup procedure and connect to that.
Any ideas, please?
Oliver Sturm
omnibus ex nihilo ducendis sufficit unum
MSN oliver@.sturmnet.org Jabber sturm@.amessage.de ICQ 27142619
hi Oliver,
"Oliver Sturm" <oliver@.sturmnet.org> ha scritto nel messaggio
news:pan.2004.06.18.10.39.55.285051@.sturmnet.org.. .
> Hey,
> I have the following problem with deployment of MSDE. Here's what I want
> to do:
> - I want to install MSDE in a named instance, even if it wasn't installed
> before.
> - I want to connect to the local server only, if possible with a
> "generic" name, so I don't have to look up the system name
> and stuff.
> I can't really get this to work at all. I have connection strings that
> work fine on development machines (where the default instance name is
> used), using . for the server name. On the test machine, using
> .\MYINSTANCE doesn't work at all. I read suggestions to use
> (local)\MYINSTANCE instead of .\MYINSTANCE, but to no avail.
> The funny thing is, even SYSTEMNAME\MYINSTANCE doesn't work unless there's
> a default instance running on the same machine. Plus, it seems cumbersome
> to have to find out the system's name for such a purpose.
> Maybe I'm just seriously wrong about something... I didn't think it would
> be that hard to set up a local (!, no networking enabled) database server
> using the standard (!, they do say I'm to use a vendor-specific instance,
> don't they?) setup procedure and connect to that.
> Any ideas, please?
that's weird, becouse (local)\InstanceName shoul'd be fine..... ok, I'm
running a pc with a default instance and a named instance...
as regard the ComputerName part, remember you are trying to connect to a
service specified on the target pc...
you can always set an Alias via Client Network Utility, but this is not the
case... but building the connection string using something similar to Public
Declare Function GetComputerName Lib "kernel32" Alias "GetComputerNameA"
(ByVal lpBuffer As String, nSize As Long) As Long, appending the
"\YourInstanceName", in your preferred language, coul'd solve the problem
too...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.8.0 - DbaMgr ver 0.54.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
sql

My SQL server doesn't exist?

So here's what happened:
I was running out of space on my DB partition (there was a sudden surge in
DB size due to a lot of scanned documents being attached in a short period
of time). To free up space for a day or two while I waited for an
additional drive to add to the RAID set, I decided to temporarily move an
older, infrequently-accessed database to another volume. Here's what I did:
- I stopped the server and server agent services for the database I was
moving -- I'll call it Old-DB -- , then simply copied its entire MSSQL
folder, lock stock and barrel, to a network share on another server.
- When the new drive arrived a day later, I added it to the RAID set and
increased the size of the volume.
- I rebooted the SQL server for reasons unrelated to this issue. On
startup, it reported that a driver or service had failed because the Old-DB
had tried to start, but of course it's MSSQL folder wasn't there.
- I copied the MSSQL folder for Old-DB back to its original location on the
SQL server.
Now I get a 1053 error when trying to start the SQL Server, and a 1068 error
when trying to start the SQL Server Agent. Enterprise Manager now shows a
(local) database that's not started, with the message (Connection failed,
check SQL Server Registration Properties) under it.
If I understand correctly, my big worry shouldn't be about the data (which
is probably fine), but about the user logins. Is that right?
What's my next step to getting this DB back online? It's not urgent, but it
IS important that we retain or regain access to the historical data in this
DB.
Thanks in advance!
BJ
I have a full disk image of the SQL server that was taken just prior to
retiring the database and migrating to the new version of the application.
I'll restore that image to temporary hardware, verify that I can access the
DB, and then use Books Online to lookup and follow an accepted procedure for
moving or restoring that database to a new server.
Thanks for cutting to the chase. :-)
BJ
"Mark Yudkin" <DoNotContactMe@.boingboing.org> wrote in message
news:uwx0LO8NHHA.4172@.TK2MSFTNGP04.phx.gbl...
> You should perform a full system restore to recover to the state you were
> in before you started moving files.
> Then start again and do the job "correctly" i.e. by following the
> documented procedures (see Books Online) for moving databases.
> "Bryan L" <blinton.nospam@.connellinsurance.nospam.com> wrote in message
> news:e3%235claNHHA.2232@.TK2MSFTNGP02.phx.gbl...
>