Nancy

>Thanks for your reply. I guess I should have explicitly stated that I am using ADO.NET. I found that using a mapped drive for a data path wasn't allowed, so my concern was/is that a share on another server will have the same problem. I don't think that is the same problem, but I am just a little fried and thought I should get a reality check.

>The situation is a client will be rebuilding their server (I hope) and dividing the work up on two boxes. It's a sticky situation and I don't want to miss some small but critical detail.

The problem with the mapped drive scenario (based on the experience I've had) was that the data located on a remote server was not seen as a resource that the ASPNet user had rights to.

Below is a link that outlines the ASPNet user permissions (for whatever reason the article starts about mid-way down the page)
http://www.dnzone.com/ShowDetail.asp?NewsId=562

Not for sure how (or even if possible), but if you could give the ASPNet user (on the web server) rights to the remote drive containig the data, a UNC or mapped drive would work.

(My own opinion) It almost seems like MS really tried to push people to use SQL server as the data back end. The ASPNet is a very good idea for the sake of security. However, it sure hurts when trying to access data in a file on a remote machine.

If memory serves correctly, the only way I was able to get around the problem was by using OBDC.net (a sub-set of ADO.net) ... However, you may take more of a perfomence hit by using ODBC.net than leaving the data on the same server as the web site.

Below is a link to the ODBC.net stuff on the MS site (simply as an option)
http://www.microsoft.com/downloads/details.aspx?FamilyId=6CCD8427-1017-4F33-A062-D165078E32B1&displaylang=en

Hope that helps...

Thanks,
Danny