I unexpected delete SQL File Stream Shared location, is there a way to restore the Shared location. When i try to open SQL File table from SSMS Explore File Table Directory it works on Server, but it doesn't allow to open from client machine. I already enabled Remote Access for SQL File Shared. Is there a way to restore back.
Also can any one suggest me unable to open File Explorer from SSMS. it shows unauthrised access
Related
I am running a file upload process to upload files to a db. The web server and the SQL server are different machines. I am attempting to use an SQL OPENROWSET to upload an excel file, but I cannot determine how to get the file onto the other machine. Is there a way to set up a shared drive that the web server can save a file to and the SQL server can access? We have a local network set up with Active Directory.
For Example:
WebServer - Shared drive on web server under C:/inetpub/webpage/fileImport
SQLServer - Will log in with sql auth using USERID and PASSWD. Needs to access webserver shared drive.
What user do I share the drive on web server with so that the sql auth user will be able to access it when I run the OPENROWSET?
Any help will be much appreciated.
I am also trying the same thing by uploading the file in FTP and trying to access it. But i didn't get any progress from last 2 weeks.
And i had found may other alternatives like coping the files in another server and share the folder with out user name & password. then we can able to access it by giving the
\\folder\filename
If u get any other alternative plz share...
You should setup a new user that has access to the user group iis_users, and then give them security access to the file drive itself.
The same should be done to the DB server, and on the drive folder security the other user will need read/write/Modify permissions.
So it will look like:
(WebHost) ---- (Shared) ---- (DBHost)
*-------*
Well, you would setup the folder on the SQLServer.
Create a secure user on the SQL machine.
Make the folder shared (with modify rights for the secure user)
Map the Network drive on the Windows machine, using the secure user to access it.
Your main user on the SQLServer should then be able to openrowset from the local folder, whilst the IIS Server is remotely accessing it.
Using the OPENROWSET means that SQL qill access files using the service account. This account must be used to access share drive, as stated here Using SQL Credential to Open a file with OpenRowSet.
I have an issue where occasionally I need to work at Starbucks.
When I upload a PHP file the connection is slow so if a user tries to access the PHP file while I am uploading it they will of course be issues a fatal error.
This is very inconvenient to my busy websites. Is there a way that when a file is uploaded it can be uploaded to a temporary location, and then the server moves it to the real location once finished?
You can make WinSCP upload the file to temporary file and rename it once transfer completes automatically.
In Preferences go to the Transfer > Endurance tab and select All Files in the Enable ... Transfer to temporary file name box.
For details refer to:
https://winscp.net/eng/docs/ui_pref_resume
Why don't you just upload the file to a temporary folder on the server and execute commands on the server to remove the old file and move the new file? It should move the file fast enough on the server to eliminate any hiccups the users would see unless their timing was just right.
I'm trying to go through multiple .trc files to find out who has been logging into SQL Server over the last few months. I didn't setup the trace, but what I've got are a bunch of .trc files,
ex:
C:\SQLAuditFile2012322132923.trc,
C:\SQLAuditFile201232131931.trc
etc.
I can load these files into SQL Profiler and look at them individually, but I was hoping for a way to load them all up, so that I can quickly scan them for logins. Either using a filter, or better yet, load them into a SQL Server table and query them.
I tried loading the files into a table using:
use <databasename>
GO
SELECT * INTO trc_table
FROM ::fn_trace_gettable('C:\SQLAuditFile2012322132923.trc', 10);
GO
But when I do this, i get the error message:
File 'C:\SQLAuditFile2012322132923.trc' either does not exist or is not a recognizable trace file. Or there was an error opening the file.
However, I know the file exists, and I have the correct name. Also they appear to be recognizable because I can load them up into SQL Profiler and view them fine.
Anybody have an idea why I'm getting this error message, and if this won't work, perhaps another way of analyzing these multiple .trc files more easily?
Thanks!
You may be having permissions issues on the root of C:. Try placing the file into a subfolder, e.g. c:\tracefiles\, and ensuring that the SQL Server account has at least explicit read permissions on that folder.
Also try starting simpler, e.g.
SELECT * FROM ::fn_trace_gettable('C:\SQLAuditFile2012322132923.trc', default);
Anyway unless you were explicitly capturing successful login events, I don't know that these trace files are going to contain the information you're looking for... this isn't something SQL Server tracks by default.
I had pretty much the same issue and thought I'd copy my solution from
Database Administrators.
I ran an SQL trace on a remote server and transferred the trace files to a
local directory on my workstation so that I load the data into a table on my
local SQL Server instance for running queries against.
At first I thought the error might be related permission but I ruled this
out since I had no problem loading the .trc files directly into SQL Profiler
or as a file into SSMS.
After trying a few other ideas, I thought about it a bit more and realised
that it was due to permissions after all: the query was being run by the SQL
Server process (sqlsrvr.exe) as the user NT AUTHORITY\NETWORK SERVICE –
not my own Windows account.
The solution was to grant Read and Execute permissions to NETWORK
SERVICE on the directory that the trace files were stored in and the trace
files themselves.
You can do this by right-clicking on the directory, go to the Security
tab, add NETWORK SERVICE as a user and then select Read & Execute for
its Permissions (this should automatically also select Read and
List folder contents). These file permissions (ACLs) should automatically
propagate to the directory contents.
If you prefer to use the command line, you can grant the necessary permissions to
the directory – and its contents – by running the following:
icacls C:\Users\anthony\Documents\SQL_traces /t /grant "Network Service:(RX)"
I am doing a project of a web enabled database. I have created the database file in my PC.
Now when I just want to open .mdf i.e. of the database I created, I cannot open it in other PC. I even had copied the .ldf file i.e the log file to that PC.
Since I need to transfer the database to the Server later, I don't know how I will dump the database in that server from my PC so that the company can use it.
The basics of using mdf file is like this:
Create a new database using SQL Server (set the path for the file as you wish)
If you wish to move the file elsewhere,
detach the database from your server
copy/move the file to wherever you wish
attach the file as database in SQL server
You are not supposed to open the file by double-clicking as mime setting or attachment of extensions migh not be there in the target machine.
Why don't you use the decent method to copy/move database?
For a NUnit test I need to reference a .mdf file from a .config file. Unfortunately, I get the following error message:
The FOR ATTACH option requires that at least the primary file be specified.
An attempt to attach an auto-named database for file
C:\....\*.mdf
A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
I looked for this error on google but didn't find anything that helped me solve my problem.
Any idea?
Thank you
Edit
Apparently the .log file is missing.
Yeah, as snippy as it sounds:
A database with the same name may already exist (database name possibly != file name).
The specified file may not be something SQL Server has access to
Is the file unique and not bound to the server at the same time (like from another unit test)? Does the SQL Server service account have access to the file?