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
Related
I need to connect to a remote database (Oracle) using a MS SQL Server (2019) linked server. What I did so far:
Installed Oracle Instant Client x64 and the ODBC drivers on the machine where the SQL server is running
Created a symlink to the central TNSNAMES.ORA (on a file share in the network) inside the Oracle Instant client folder.
Set the necessary environment variables
Created an ODBC connection to the database on the Oracle server on this machine
Restarted MS SQL Server
Created a linked server (Microsoft OLEDB Provider for ODBC Drivers) in the SQL instance
When connecting to the SQL Server using sqlcmd on this machine (I did not install SSMS there), I can query the linked database using OPENQUERY(). I can also read the file TNSNAMES.ORA using this command (note, the given file is the symlink, but it displays the contents of the linked file, as it should):
SELECT * FROM OPENROWSET(BULK 'C:\InstantClientx64\tnsnames.ora', SINGLE_CLOB) TNSNames
So far, everything is fine.
Now, when I connect to the SQL Server from my workstation using SSMS, i get the following error when trying to read TNSNAMES.ORA using the command above:
Cannot bulk load because the file "C:\InstantClientx64\tnsnames.ora" could not be opened. Operating system error code 5(Access is denied.).
I created a file test.txt in the instant client folder containing something like "Am I allowed to read this?" - and I was, no problems.
I started procmon on the server to find out what happens. When using the above command on the SQL server, I get a REPARSE (because it's a link!), and then SUCCESS, the file is displayed in the sqlcmd console.
When using this command in SSMS (on my local workstation), first appears the REPARSE (OK), then ACCESS DENIED.
In both cases it is the same user account which is displayed as "Impersonating" in the procmon's details. There is definitely no problem with a firewall, and the read permissions on the tnsnames.ora file on the network share are granted for Everyone. I am also able to create an ODBC item on the local workstation, and can connect and query the database from here.
I have done this in the past I don't know how often, and never had problems. What am I missing?
Why are you trying to read the tnsnames.ora file via SQL? The Oracle libraries will (should) internally open it and use it when your app connects to the DB.
The default location for network config files is shown in the Instant Client installation doc. In your case it will be C:\InstantClientx64\network\admin. Unless you have set the TNS_ADMIN variable, then start by creating this subdirectory and putting tnsnames.ora in it.
(A future version of Instant Client on Windows will create the network\admin subdirectory automatically, similar to the way it is created with the Linux Instant Client packages).
I have two server. Server A is the application server, and server B is the database server. Normally I use SQL Management Studio in Server A to query. I intend to do a database backup (.bak), but whenever I do this through SQLMS, the file is created at server B. I dont have access to do a remote connection to server B.
How do I get the backup file?
You can specify a UNC path for the target of the backup. Keep in mind, however, that the account that the SQL Server service runs under will need network access to that path. This is one good reason why the SQL installer asks you which account to run the services under.
I ended up using generation script. But instead run all in a single script, I run 3 different script (create table, create stored procedure, and data) at a time. I do this because if I run in a single script, I ended up an error. By the way, the script can be compressed (zip) to give a smaller file size.
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’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