Data File in a Different machine on the network.

Hi All,

I have a requirement to create the database with data and log files in
a different machine on the network.

Googling, I got a link which said Mapped drives do not work but UNC paths
work. However in my case, both are failing.

Any advices or links on net will be highly useful.

Thanks and Regards,
Chandra MohanDon't do this. It's not supported by Microsoft, you will lose all the
benefits of a client-server database and you risk corrupting your data.

Read this article:

http://www.mssqlserver.com/faq/gene...tworkdrives.asp

--
David Portas
----
Please reply only to the newsgroup
--|||bschandramohan@.yahoo.com (Chandra Mohan) wrote in message news:<bb0ef6.0309282105.59f0d698@.posting.google.com>...
> Hi All,
> I have a requirement to create the database with data and log files in
> a different machine on the network.
> Googling, I got a link which said Mapped drives do not work but UNC paths
> work. However in my case, both are failing.
> Any advices or links on net will be highly useful.
> Thanks and Regards,
> Chandra Mohan

Check this KB article:

http://support.microsoft.com/defaul...1&Product=sql2k

You can put database files on network drives by setting trace flag
1807, but it is not supported unless the files are on a NAS which is
specifically certified for SQL Server. Often, the NAS will make the
network drive appear like a local one, so you won't need to set the
trace flag on anyway.

Putting a database on a normal UNC share is a very bad idea - you
won't be able to guarantee data integrity and performance will suffer.

Simon|||David Portas (REMOVE_BEFORE_REPLYING_dportas@.acm.org) writes:
> Don't do this. It's not supported by Microsoft, you will lose all the
> benefits of a client-server database and you risk corrupting your data.

I agree that putting a database on a network drive is an extremely bad
idea, but I don't see where the client-server issue comes in. You can
still connect a lots of clients to that database, as if the database
had been a drive local to the database server. (Well, lots and lots.
If there are lots, corruption might appear within the hour.)

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||What I had in mind was that you lose the performance advantage (compared to
a desktop database running on a network) of server-based processing. And you
sacrifice much of the resilience of transaction management and logging.

--
David Portas
----
Please reply only to the newsgroup
--

"Erland Sommarskog" <sommar@.algonet.se> wrote in message
news:Xns9405EBB63563DYazorman@.127.0.0.1...
> David Portas (REMOVE_BEFORE_REPLYING_dportas@.acm.org) writes:
> > Don't do this. It's not supported by Microsoft, you will lose all the
> > benefits of a client-server database and you risk corrupting your data.
> I agree that putting a database on a network drive is an extremely bad
> idea, but I don't see where the client-server issue comes in. You can
> still connect a lots of clients to that database, as if the database
> had been a drive local to the database server. (Well, lots and lots.
> If there are lots, corruption might appear within the hour.)
>
> --
> Erland Sommarskog, SQL Server MVP, sommar@.algonet.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp|||David Portas (REMOVE_BEFORE_REPLYING_dportas@.acm.org) writes:
> What I had in mind was that you lose the performance advantage (compared
> to a desktop database running on a network) of server-based processing.
> And you sacrifice much of the resilience of transaction management and
> logging.

You mean that rather running client on machine A and server on machine B,
we're running both server and client on A, and only have the database files
on B.

Yes, this is killing the client-server concept. (Ever heard of Visual
SourceSafe? That's an example of this architecture.)

I don't know why people want to put databases on network devices, but
my assumption is that the most common reason is simply space constraint
on the server, so they try to rent space somewhere else in the network.
In this case, I guess clients still connect from somewhere else.

But rather than renting the space, it's better to rent the entire disk
and move into cabinet. Or see your local hardware dealer...

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp