I've searched similar topics looking for something closer to what I need, but I haven't had any luck yet. I'm working on a card ID import application, where I need to trigger a SQL job from the user's workstation to import the data into a different database. I did see one post about triggering a job locally from the command line on the local SQL server, but I need to see if I can do this remotely from inside the .NET application.
I already have a connection to the SQL server so that I can import the user information into the photo ID database, but once they have been imported, I need to kick off the scheduled job to run so that it will complete the process.
Use ADO.NET and send the following stored procedure sp_start_job (Transact-SQL) to the msdb db. Here is the MSDN docs.
http://technet.microsoft.com/en-us/library/ms186757.aspx
Related
I'm trying to find a bug on a store procedure(SQL server) that gets executed from a console application coded in C#. Is there a way I can do some sort of breakpoints into the Store Procedure scripts and find how the data gets processed into the store procedure in real-time?
I know that you can debug a simply Stored procedure on Visual Studio. But what I want to do it's to debug it in real-time with the console application.
Dependent on which version of SQL Server you are using you will want to use either SQL Server Profiler or Extended Events, see Quick Start: Extended events in SQL Server and SSMS XEvent Profiler.
I am checking one SSIS job execution report, which shows me the below report:
The most recent one succeeded, but when you take a look at ID:217583, it is still running and never finished (duration keeps increasing), and when I check the job activity in sql server agent, that execution should failed before, the reason why I said that was because the start time matched. Here is the job history in sql server agent :
So I assume this job execution failed but for some mystery reason, it still shows (or running) in the background with 'running ' status.
Does anybody have any ideas? I tried to EXEC msdb..sp.stop_jobscommand, but cannot locate that job ID.
Can anybody tell me what was really happened? Is this job still running somewhere else? If so, how to locate that job execution and stop it? Or how to let the report does not show this weird record anymore?
Thx in advance :)
If your are executing this package as a job from the SSISDB, you can use the stop operation procedure as follows.
USE SSISDB
GO
EXEC [catalog].[stop_operation] 217583
https://msdn.microsoft.com/en-us/library/hh213131.aspx here is a reference to stopping operations. In case this link breaks, ...
The SSISDB database stores execution history in internal tables that are not visible to users. However it exposes the information that you need through public views that you can query. It also provides stored procedures that you can call to perform common tasks related to packages.
Typically you manage Integration Services objects on the server in SQL Server Management Studio. However you can also query the database views and call the stored procedures directly, or write custom code that calls the managed API. SQL Server Management Studio and the managed API query the views and call the stored procedures to perform many of their tasks. For example, you can view the list of Integration Services packages that are currently running on the server, and request packages to stop if you have to.
Viewing the List of Running Packages
You can view the list of packages that are currently running on the server in the Active Operations dialog box. For more information, see Active Operations Dialog Box.
For information about the other methods that you can use to view the list of running packages, see the following topics.
Transact-SQL access
To view the list of packages that are running on the server, query the view, catalog.executions (SSISDB Database) for packages that have a status of 2.
Programmatic access through the managed API
See the Microsoft.SqlServer.Management.IntegrationServices namespace and its classes.
Stopping a Running Package
You can request a running package to stop in the Active Operations dialog box. For more information, see Active Operations Dialog Box.
For information about the other methods that you can use to stop a running package, see the following topics.
Transact-SQL access
To stop a package that is running on the server, call the stored procedure, catalog.stop_operation (SSISDB Database).
Programmatic access through the managed API
See the Microsoft.SqlServer.Management.IntegrationServices namespace and its classes.
Viewing the History of Packages That Have Run
To view the history of packages that have run in Management Studio, use the All Executions report. For more information on the All Executions report and other standard reports, see Reports for the Integration Services Server.
For information about the other methods that you can use to view the history of running packages, see the following topics.
Transact-SQL access
To view information about packages that have run, query the view, catalog.executions (SSISDB Database).
Programmatic access through the managed API
See the Microsoft.SqlServer.Management.IntegrationServices namespace and its classes.
I have a package that has a main sql execute task. Within that task I need to call two databases (A,B) each on a different server. There is a linked server(B) within the main server(A) I am using. I can't split them out however due to they join on each other many times on many different tables in separate scripts. The main script is a large amount of unions pulling data in to report off of in a later task.
I have my linked server call in my sql script but it says it can't connect. Is there a way I can connect to this linked server as I do when I run the sql script from sql server? Or is there a way to make a connection within the SSIS package and refer to it somehow within a task or in the script?
Make sure Proxy Account has setup proper Login credential/user with permission to execute your task at main server(A) and able to access linked server(B).
Use Log Viewer at SSMS to see the error message.
See example at following URL:-
https://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/
Similar to this post
I have an SSIS Package with a Script Task that creates an Excel file on disk and populates it with data from a SQL Stored Procedure (using Microsoft.Office.Interop.Excel). This works great when testing and when running the deployed package manually through the SSIS Catalog, but when I schedule the task to run automatically through SQL Server Agent, the Package fails in the Script Task step. I have the Job running as a Proxy account that is the same as the account I'm logged into the server with when testing (and the same as the account that works when manually running the packages).
My understanding is that even though the job is running using a Proxy, any desktop interaction occurs within the Profile context of the SQL Server Agent login. Since that profile isn't actively logged in, the interaction fails. Digging in more, there is a bool System Variable in the package called "InteractiveMode" that is set to "False". I have a feeling that if I could switch that to True, everything would be hunky dorey. Trouble is, that variable is only accessible to my Script Task as "ReadOnly"...
Is there any way to set the System:InteractiveMode Variable in an SSIS package manually or programatically at runtime? Please help! I'm having to run these scheduled jobs manually for now, which is a big pain.
Thanks.
I had this problem a few months ago and it turned out that the execution options needed to be set to use 32 bit runtime. If you're using SQL Server 2008 R2, you can open your job and double click on the step. It's under the Execution Options tab.
If you continue to have errors, you may want to consider changing the package so that it uses a file system task to create/rename the excel document and then a Data Flow Task to move the data from your stored procedure to your excel document. Depending on your data, you may need to add a Data Conversion step in between. Here's a good article on the topic: http://www.mssqltips.com/sqlservertip/3046/sql-server-integration-services-data-type-conversion-testing/
Edit:
I haven't used SQL Server 2012 yet, but according to MSDN, it looks like the option is under the Configuration tab. Here's their article: http://msdn.microsoft.com/en-us/library/gg471507(v=sql.110).aspx
I have a database on one server that I need to copy to another server. I can do this manually using the Export Data task, which is fine for a one time export, but I would like to speed this up as it is going to be repeated.
The database will always contain the same set of tables, I just need to get a copy of this database with it's tables and their data from one server to another.
I'd like to create some sort of reusable tool that allows you to specify the source and target database servers and then copies this specific database from one to another. Is this possible?
The Export Data task in SQL 2005 and later uses SQL Server Integration Services (SSIS) under the hood. You can save the package you're already using and run it on a schedule or on demand. You can also edit it (once it is saved) using the Business Intelligence Development Studio (BIDS).
At the end of the Export wizard (on the "Save and Run Package" screen), you can tick the "Save SSIS Package" check-box to store the package either within SQL server or on the file system. The file system is probably simpler.
Once you have the package you can execute it from the command line using the dtexec tool, or from a SQL Agent job using an Execute SSIS task.
SSIS is too big a subject to cover in full here - there are decent tutorials within SQL server books online if you need more details - alternatively, as another SO question if you get stuck.