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.
Related
I have an SSIS package that creates 2 text files using a data flow component. It connects to an SQL database and if the query returns data, the 2 files are created.
After that, a script task loops through the folder where the 2 files are written into, determines the oldest file and moves it to another folder.
Everything moves smoothly when I execute the package on the server. No errors and all functions are executed. Perfect.
However, when I schedule the SSIS package in a job, the said script task only gets executed when the SQL query (data flow component) returns no results and therefore no files are created. The script then moves the 2nd file from the last run to the other folder.
If the data flow does create 2 new files, the script task does not do anything.
Any ideas how to change this behavior?
Again, this only happens when executed through a job, not when run locally.
Thanks,
Daniel
When SSIS packages are executed from SQL Server they access file system using the SQL Server Service Account NT SERVICE\MSSQL$<Instance Name> (Where <Instance Name> should be replaced by the installed instance name). You have to Grant this account to access the selected directories or run the SQL job using a proxy account:
SQL Server Service account Permissions:
Configure File System Permissions for Database Engine Access
Setting proxy account:
Running a SSIS Package from SQL Server Agent Using a Proxy Account
Create a SQL Server Agent Proxy
The package is running using a proxy account. All the other package are running and saved in the same folder. In this one the file saved in this folder has to move to a different one which saves to differnt application which uses third party dll.
I am calling the library using reflection. But the dll is not registered in sql. Will that be a issue?
I have set up 2 separate Database Engine connections in SSMS 2017. One connection is to the company server databases and the other is for my local database instance. Now, when I open SQL files with code referring to the Server Instance (#1), it fails to run because it doesn't recognize the tables or the attributes. I have to right click on the Server Name in the Object Explorer and open A New Query page, copy the code from the SQL file and paste it onto the new Query page and then run it.
How do I get the SQL file to run by opening it and clicking on Execute?
If you are trying to reach a different database instance from your local hosted instance, you will need to create a linked server.
Once you have that in place you can mix the database connections from a single sql file by using 4 part naming conventions [Server].[Database].[Schema].[Table].
I stopped SQL Server (MSSQLSEVER) and SQL Server Agent services and deleted the backup file and data file was located at C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL. Log file is still there:
Now I can't connect to SQL Server
Can not start SQL Server (MSSQLSERVER) and SQL Server Agent services as well
Could you suggest me a solution to connect to my SQL Server instance?
Image of the error message:
I really do not have enough information to diagnose this issue.
However, I have two ideas of what you did.
1 - What you showed me in the picture is the data and log directories. They contain all the system databases by default. See image below.
If you have not done a shift delete of the files and directory, stop the sql server instance and recover them from the recycle bin and restart the sql server instance.
Be VERY careful when deleting directories.
If you do not have these files handy, you might have to re-install SQL Server.
2 - If you data files are in another directory, which I doubt. Then, look in the windows event log and/or sql error log for errors. Please post more details.
J
You're not going to be able to connect to the SQL until the agent service is running again.
I think I need more information about what happens when you try to start the service. Also, I'd probably (if possible) try to restart the machine. Though that probably shouldn't be necessary, dependent on OS you're running it might help.
If you could post what happens when you try to start the service, that might be helpful.
Is the SQL service running? The agent service is not required for connecting to an instance. To regain access to SQL server after deleting required files, read the following msdn article: https://msdn.microsoft.com/en-us/library/dd207004(v=sql.120).aspx
I have the following situation:
A sql server 2014 is installed
While the server was shutdown the hard drive the databases were on had troubles which resulted in the loss of these files
So now I have the situation that the server has databases configured to be existing where the files don't exist any longer.
When I now try to start the sql server via the configuration tools it does not start and in the log files I see that he throws an error that he doesn't find the database files. When I tried to copy the same files there from another server I still had the same problem but the error message was now "access denied" (as naturally they had different users).
So my question is: What (aside from a reinstall) can I do to get the sql server up and running again?
Change the database file permissions to allow access for SQL Server. Look at an existing file to see what permissions must be configured.
I'm having a rather frustrating issue with using an SSIS Flat File source. I am developing an SSIS package on my local machine via VS 2008 and I'm using a flat file source that is stored locally. However, I need to deploy this package to a remote server that hosts our SQLServer and then run it as a scheduled job from that host. However, when I deploy the package, it obviously can't read the flat file source from my machine and fails the job. I have tried putting the file directly on the remote host in the exact same file location (ie. C:\Source.txt) but to no avail. Any ideas on how I can get my deployed SSIS package to read a flat file source?
Hopefully I'm just missing something extremely simple and will ultimately have a "DUH" moment, but if anyone can help I will greatly appreciate it.
If the account under which the SSIS package (for instance the SQL Server Agent service account) is running doesn't have rights to open the file, you will also have problems. So not only does the file need to be on a path that is valid relative to the server running the package, it must also have rights.
Nice answer by Cade.
Remember that you create a SQL Server Job, by default it runs under the credentials of the Service Account assigned to the SQL Server Agent.
If some steps on a Job need some permissions not owned by the Service account you can define a SQL Server Agent Proxy.
That way you can keep the principle of least privileges.
More info on how to create a Proxy here.