server, using Enterprise Manager. I then exported some data from another
database (same instance) into my new database. I then detached the database
I created, and copied the .MDF and .LDF files to my machine.
I've been trying to attach the .MDF and .LDF files, again using Enterprise
Manager (I'm also running SQL Server 2000). In EM, I tell it to Attach
Database... I give it the path to my .MDF and .LDF files, hit Verify, and
they verify (both the .MDF and .LDF file paths show up in the window,
checked). The problem comes when I hit OK. It gives me error 5105 (device
activation error), it gives the same path that I gave it, and says that the
filename may be wrong.
I don't think this is a permissions problem, and I've checked whether any
other process has grabbed ahold of it, and there isn't any. So I'm not sure
what's wrong. Please help.
Thanks.
Miller -
Please go through the following link :-
http://support.microsoft.com/default...b;en-us;304261
Let me know if you where able to get the help for your problem.
Regards
"Mark Miller" wrote:
> Here's what I did. I created a new database on SQL Server 2000, on a remote
> server, using Enterprise Manager. I then exported some data from another
> database (same instance) into my new database. I then detached the database
> I created, and copied the .MDF and .LDF files to my machine.
> I've been trying to attach the .MDF and .LDF files, again using Enterprise
> Manager (I'm also running SQL Server 2000). In EM, I tell it to Attach
> Database... I give it the path to my .MDF and .LDF files, hit Verify, and
> they verify (both the .MDF and .LDF file paths show up in the window,
> checked). The problem comes when I hit OK. It gives me error 5105 (device
> activation error), it gives the same path that I gave it, and says that the
> filename may be wrong.
> I don't think this is a permissions problem, and I've checked whether any
> other process has grabbed ahold of it, and there isn't any. So I'm not sure
> what's wrong. Please help.
> Thanks.
>
|||I tried turning on trace flag 1807, like the article says, to turn off the
check SQL Server does to detect if I'm accessing a database file through a
network share, and I get the same error. I gave this a try because it seemed
to be in the ballpark of my problem, but I'm not trying to access the
database file over a network share anyway. It's on my computer's hard drive.
Other than this bit of information in the article, nothing else in it seemed
relevant.
"surajits" wrote:
[vbcol=seagreen]
> Miller -
> Please go through the following link :-
> http://support.microsoft.com/default...b;en-us;304261
> Let me know if you where able to get the help for your problem.
> Regards
>
> "Mark Miller" wrote:
|||When you did the backup, did you specify a device or a file? If a device and
you are restoring from the file, you may be seeing a header conflict.
"Mark Miller" wrote:
[vbcol=seagreen]
> I tried turning on trace flag 1807, like the article says, to turn off the
> check SQL Server does to detect if I'm accessing a database file through a
> network share, and I get the same error. I gave this a try because it seemed
> to be in the ballpark of my problem, but I'm not trying to access the
> database file over a network share anyway. It's on my computer's hard drive.
> Other than this bit of information in the article, nothing else in it seemed
> relevant.
> "surajits" wrote:
|||I wasn't trying to back up data. I wanted to transfer data from one database
to another, because I'm working on a software development project. The
source database is behind a firewall, and I can't access it from my
application on my development system. All I need is a subset of the data on
the source database. So I decided to create a new database on the source
instance, export the data I needed into it, detach it, and then copy it to my
machine, where I have my own SQL Server 2000 instance, and where I was
planning on accessing it from my application. I transferred it using a
straight network file copy process (ie. copy from source file system and
paste to destination file system). No tape backup was involved. Is the
picture getting clearer now?
Forgive me for not making this clearer. Isometimes forget I'm not always talking to other developers.
"jrpm" wrote:
[vbcol=seagreen]
> When you did the backup, did you specify a device or a file? If a device and
> you are restoring from the file, you may be seeing a header conflict.
> "Mark Miller" wrote:
|||I suggest to first try doing this from Query Analyzer using sp_attach_db and make sure you get the
parameters correct. Possibly, you need to specify correct path for the ldf file if not in same path
as on original SQL Server. If that doesn't work (and you feel that you got the parameters correct),
I'd try to attach the original files (before the file copy) on the originating server. If that work,
I'd copy the files over the network back onto the originating server and try to attach those
files...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Mark Miller" <MarkMiller@.discussions.microsoft.com> wrote in message
news:6637F49E-D3B5-4C20-800B-45CB72EE5F78@.microsoft.com...[vbcol=seagreen]
>I wasn't trying to back up data. I wanted to transfer data from one database
> to another, because I'm working on a software development project. The
> source database is behind a firewall, and I can't access it from my
> application on my development system. All I need is a subset of the data on
> the source database. So I decided to create a new database on the source
> instance, export the data I needed into it, detach it, and then copy it to my
> machine, where I have my own SQL Server 2000 instance, and where I was
> planning on accessing it from my application. I transferred it using a
> straight network file copy process (ie. copy from source file system and
> paste to destination file system). No tape backup was involved. Is the
> picture getting clearer now?
Forgive me for not making this clearer. I> sometimes forget I'm not always talking to other developers.
> "jrpm" wrote:
