BULK INSERT from shared drive using sql server 2012 - sql

I have a little query that I want to bulk import from a shared network drive:
BULK INSERT
test
FROM
'\\fullpath\path\file.csv'
WITH
(FIELDTERMINATOR = ',', ROWTERMINATOR = '\n')
This doesn't work and gives this error:
Operating system error code 5(Access is denied.)
From what I've read, this is because the shared drive doesn't recognize the SQL Server user (me) because the authentications are different.
Would I be better off putting these files on the SQL Server itself, or granting some kind of permission on the shared drive? I'm not sure what to tell our IT group to do in terms of allowing SQL Server to "see" the shared drive.
Alternatively, I'm not sure how to access the SQL Server directory directly to place the CSV files. What do you all think?

You need to take a look at the SQL Server NT service on the server that hosts the SQL instance. Find out what account the NT service is running under (it could be an account that is local to the server, or a domain/AD account). That is the account that needs access to \\fullpath\path\, not the account you use to make your connection to the SQL instance.

Related

Unable to connect to a migrated Access database on SQL Server as another user: SQL server Error 4060

I have an Access DB that I migrated to SQL server recently. The SQL server is on a Windows server. Now I can work normally with the SQL database but when others log into the same windows server with their credentials they are not able to access the database. As soon as they open Access frontend they get an error saying failed connection. Now I created an ODBC connection string(File DNS) and gave it to the other users in the network but they still are not able to connect to the database. They get an error stating "SQL server connection failed. The server rejected the connection: Access to the selected database has been denied". Can someone please help me to solve this issue so that multiple users can connect to the SQL DB without any issues? Thanks
Hard to know with the limited information. Are you using windows authentication to sql server, or are you using SQL logons? Either should work fine. The other issue to watch out for is what sql driver did you use to link with?
If you link say using the native 17 ODBC driver, then that is not installed on workstations by default - you have to download and install that driver.
Or, maybe you linked using the long time "legacy" sql driver - that is by default installed on all workstations.
So, it not clear if you using SQL logons, or using Windows authentication for the connection to the database????
If your using windows authentication, then all those other users will require permissions to be granted to the database.
If you using a SQL logon, then that logon would have been saved when you link the table(s), and again it should work for all users. Its quite common to create ONE logon on SQL server, link using that logon, and thus all users will be connecting to the database using the one same logon id/password.
And, if you linked using a FILE dsn, then zero configeration should be required, since access converts FILE dsn's into what are called dsn-less connections. (the origonal file is not required anymore once you link - you can even delete that FILE dsn, and it will still work).
So, FILE dsn is the best choice, since that dsn is NOT required to be setup on each workstation.
And if you using sql logon's, then make sure you checked the box to remember the password during linking of the tables. That is this check box:
And note during a re-link the above box does not appear - only on first time linking of table(s).

Cannot open backup device - SQL Server on-premise backup database to Azure storage

I have a database running on an on-premise SQL Server instance. I've set up a SQL agent to backup the database every night and store in a container in Azure. However, I'm seeing the following error after the job runs:
Message
Executed as user: NT SERVICE\SQLSERVERAGENT. Cannot open backup device 'https://mystorageaccount.blob.core.windows.net/mystoragecontainer/20200102/MYDATABASE_0.bak'. Operating system error 50(The request is not supported.). [SQLSTATE 42000] (Error 3201) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013)
The Azure storage account is Storage (general purpose v1).
SQL Server 13.0.5233.0
Microsoft SQL Server Management Studio 14.0.17213.0
Microsoft Analysis Services Client Tools 14.0.1016.232
Microsoft Data Access Components (MDAC) 10.0.14393.0
Microsoft MSXML 3.0 6.0
Microsoft Internet Explorer 9.11.14393.0
Microsoft .NET Framework 4.0.30319.42000
Operating System 6.3.14393
Is there a way of configuring NT SERVICE\SQLSERVERAGENT to connect to the Azure storage container?
All the comments are valid to a certain extent. I finally fixed (term used loosely) backing up my SQL Server database to an Azure storage container using SAS (shared access signature) credentials.
Deleted the existing credential in SQL Server (under Security > Credentials)
In Azure, created an access policy under Storage Account > Container. It's important to define start and expiration dates/times, and time zones along with read, write level.
In Azure, Generate a SAS token for the container. Ensure you set the appropriate start and expiration dates/times along with the timezone. Don't rely on just UTC.
Upload a file to the container to make sure it's all ok.
In SQL Server, create the credentials. The secret should be the SAS token without the preceding ?, so just "sv=...." .
IF NOT EXISTS
(SELECT * FROM sys.credentials
WHERE name = 'https://mystorageaccount.blob.core.windows.net/mycontainer')
CREATE CREDENTIAL [https://mystorageaccount.blob.core.windows.net/mycontainer]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'sv=_my_sas_key_without_?';
Backup the database. The URL and container must match with the credentials - in this case, https://mystorageaccount.blob.core.windows.net/mycontainer .
BACKUP DATABASE [mydatabase]
TO URL = 'https://mystorageaccount.blob.core.windows.net/mycontainer/mydatabase_03012020120400.bak'
WITH FORMAT,
COMPRESSION,
STATS=5,
BLOCKSIZE=65536,
MAXTRANSFERSIZE=4194304;
GO
This seems like access related issue.To be able to back up to Azure Blob Storage, your backup command must have a valid credential that has access to the blob storage. This can be done in two ways:
Review your credentials, make sure your access key is correct and, if you’re using SAS, make sure that the access policy is defined and you are pointing to the correct container that it has access to. For more information on URL backups as well as script samples, please refer:
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-2017
Shared Access Signature
Identity and Access Key
Additional reference:
https://blog.pythian.com/how-to-fix-sql-backup-to-url-failure-operating-system-error-50/
Hope it helps.

Bulk insert from share folder

I have share folder in server A with permissions.
and I'm trying to use bulk insert from server B.
I've also added network location to server 'B' with 'A'(trying to use the local path - but nothing).
using sql server 2008 r2
the SQL authentication is: Sql server.
In addition there is no domain controller to those servers, but obviously there are under the same network .
the error is:
Cannot bulk load because the file \\\server\folder\file could not be opened. Operating system error code 5(Access is denied.).
what can I do?
thanks
The SQL Server process identity (service account) security context is used when the BULK INSERT T-SQL statement is invoked from a SQL authenticated connection. Without a domain infrastructure, you will need to either allow Everyone access to the file and share or create a local Windows account on both servers with the same account name and password. Use that local Windows account as the SQL Server service account (specified via the SQL Server Configuration Manager).

Syncing database client server in VB 2010

I'm creating a VB2010 application which will require a connection to MSSQL. Should I Install SQL 2008 on my computer then use MS SQL 2008 as my data source or skip installing SQL 2008 and use MDF instead?
Also the program must have the following requirement
Program must use SQL as their database source
End user must not install SQL server on their machine
Program must be able to update (sync) the local SQL database from SQL server on the web. (User will have option to delete everything on their local database and load everything fresh from the server or to merge the update with existing data)
Programs will (most of the time) run in an offline environment. When the user have access to internet they can update the database
The program must allow user to add,edit, delete their local database while offline
Only certain user (authorized user) can update their local database back to the serverC
Is it possible to created a program that meets all the above requirement ?
If yes, can you please clarify on how can I accomplish all points
Thank you very much
use MDF instead?
An MDF file is Sql Server.
End user must not install SQL server on their machine
and
Program must be able to update (sync) the local SQL database from SQL server on the web.
In that case, I recommend Sql Server Compact Edition. It is upgrade compatible to full Sql Server, which will make sync operations easier, but it does not require you to install the full Sql Server engine to the local system.

sql server2005 back up error : access denied

I am trying to backup my sql server 2005 database using the query
backup database marksheet to disk='e:\backup\marksheet.bak'
when i execute the query it shows the following error
cannot open backup device 'e:\backup\marksheet.bak' operating system
error 5(access is denied)
I am using windows xp
please help me..
The account running the SQL Server service does not have access to that folder.
It doesn't matter if you have access to that folder.
You need to check the security permissions on the folder you are trying to backup to. Make sure the service account (Network Service) has write permissions. It may well not do.
SQL on changing the service account changes the permissions on the critical drives it knows about but won't do it for all the drives in a server.
Try adding the domain account that runs all SQL Services to the security of "e:\backup\".