I’m trying to backup a SQL08 database to a target on a remote drive and keep ending up with error reason “1815”. This happens either when scripting the backup or using the task wizard GUI. It also occurs when attempting to use either UNC or a shared drive letter to the same path. Another machine on the network doesn’t have a problem backing up to the same path. The network location has write access open to all. Any ideas?
BTW, the successful machine is a server 2008 VPC running on Vista while the one failing is just running directly on an XP host.
check the write access to the UNC for the service account that sql server runs under.
I think you've an existing backup rename it and execute again
Related
I'm made a QT application that creates a .csv file on a network drive, connects to a MS SQL DB via an ODBC connection, and then executes a BULK INSERT. The problem is that when the program executes the query using a login, it fails with:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot bulk load because the file "\10.10.10.10\data\myCSV.csv" could not be opened. Operating system error code 58(The specified server cannot perform the requested operation.).
I need to be able to run this program from a remote computer, and specify a network path for the BULK INSERT statement. There must be some sort of permissioning that's not allowing ODBC SQL SERVER login to access network/UNC paths. What is it? What am I missing? I've tried giving the network path permissions to read from everyone and a host of other things.
Here are some test cases I've done and their results:
If I run the application on the same machine, using "TRUSTED_CONNECTION", everything works as expected regardless of file location.
If I run the application on the same machine, using a login, and a network path, I get the above error. If I use a local path (C:\ for instance), everything works as expected.
If I run the application remotely, I have to use a login, and the program fails with the above error.
Explicitly give the AD account the SQL Server Service is running under access to the share
"is this a required step to get this to work" To authenicate to a different host? Completely.
Thank you to #Larnu for the answer, this solved it
I have an SSIS package that pulls some data out of SQL Server into a .csv file, then copies the file to a network location (uses Robocopy). Runs fine as a SQL Agent job. When I use DtExec from my own machine, Robocopy fails with 'Access is denied.'
The same error occurs regardless of which network location I enter. If I use Robocopy to try to copy to a local drive on the server instead, it works fine. DtExec is running as my own account. If I use remote desktop to login to the server (again with my own account) I can access all the network shares, and run Robocopy directly no problem. I am using UNC names throughout - no drive letters anywhere.
Is it possible DtExec is running under some low-privilege account on the server that cannot access any network resources? If so, any ideas on how to work around it?
I have made a program using visual basic 2010, which contains a database. When I copy my program across to another computer and attempt to debug it, I get the following error message:
An unhandled exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
Additional information: Login failed for user 'Aaron\Aaron'.
And the following line of code is highlighted within the form load sub:
Me.Table1TableAdapter.Fill(Me.Database1DataSet1.Table1)
When I publish the program it also fails to run on any computer other than the one I created it on.
Any help would be much appreciated as I'm still very new to programming, thank you.
If you're trying to access the database over the network, use:
server="HostMachineIP\Aaron" (e.g. "10.1.1.1\Aaron") and make sure firewall port 1433 is open.
If you're transferring the database to another system, set your connection string to: ".\Aaron" - the .\ references the local system.
There are lots of things that could be the issue, but for starters, you probably don't have the same user set up on your other computer that you had on your first one. That is probably why you are getting the error about Login failed for Aaron/Aaron.
Additionally, you may well have a database on the first computer that is not on the second. Transferring the program does not copy the database with it. So you should go into SQL Server on your first computer and compare it to SQL Server on your second one. Likely there are differences in users and databases that will cause problems.
From your description, it sounds like maybe you aren't using a "server" yet.
You won't have much luck if you are moving/copying the .mdf file. Your dev environment will allow this, but not other machines. It will work better if you install SQL Express on one of your machines and use it to host your .mdf (database file). That machine will be your "server".
Download SQL Server Express and install it
Download SQL Server Management Studio. Use it to attach your .mdf. Set permissions. Allow remote connections.
Check your windows firewall (on the server) to make sure port 1433 is open (SQL server communicates across a network on port 1433.
Each machine (except for the server) will need to authenticate to the server. I find this is easier when I map a drive to the server. On the server, make a folder on the hard drive called "temp", share it to the network. On each machine, explore the network, find your server, find the share (temp), map a drive to it.
Once you have done these things, then these other recommendations will work.
My machine is a macbook pro. However, my company's data is in SQL Server. In order to access it, I need to use VMWare Fusion to run SQL Server Management Studio 2008 on Windows XP.
When I attempt to run a bulk import (via instructions from SQLAuthority.com), I get this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "H:\test.CSV" could not be opened. Operating system error code 3(The system cannot find the path specified.).
I am dealing with 3 different file locations, but none of them work.
My Mac storage - "/Users/Admin/Documents/test.CSV"
My Windows XP storage - My "C:" drive. "C:\test.CSV"
My company's network location - Mapped to the "H:" drive via Windows XP. "H:\test.CSV"
Changing the script to point to all these locations provides the same error message.
Any thoughts on how to overcome this? Presently, my only alternative is to use the SQL Server Import/Export tool, but it takes a while to setup every import. Script is faster.
A bulk insert runs from the server. So it can't reach your local disk.
The server uses the account that the "SQL Server" Windows service uses. That account typically does not have any mapped drives.
Try using a full name, like:
\\server\share\test.csv
Possible other solutions:
Ask a DBA to open a share on the server for imports
Ask a DBA to place the CSV file on a disk on the server
Ask the DBA which account is used for the SQL Server service. If it's a domain account, you can give the account read rights on a network share.
I experienced this error, too.
In my case the solution was to change the path in T-SQL from a share to the actual directory: \\server\share$\file -> drive:\folder\file.
The culprit ended up being a problem with VMWare, which caused the server to have trouble authenticating with some network shares.
I need to backup my SQL Server 2008 database to another PC on network. I've even mapped network drive and assigned it another driver letter.
But when I try to select .bak file while exporting, only C: shows up. I've even restarted my SSMS.
Can somebody point out what else I may need to do? Thanks!
You can by using SQL
BACKUP DATABASE Foo TO DISK = '\\myserver\myshare\foo.bak' WITH INIT
Make sure the account used for the sql services has enough rights to write to the other pc.
For the reason the mapped network drives don't show up made with your user account. This has to do with the Sql Server service running under another user account then the one you've used for mapping the drive.