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/
Related
I am attempting to create a new database in an existing sql server from code first. I used package manager to enable migrations, add a migration, then update database. The three methods executed without any errors and I got the traditional massages afterwards. However, when I look in either MSSSMS or Server Explorer I don’t see the database. I tried re-running the update database command and got the migration has already been applied. Any suggestions?
Update:
I've figured out that the project is adding the database to localdb. However, I have a connection string in the app.config file.
Probable causes are:
the database was never created
you use a login that can't see the database. Using Windows authentication/sa might allow you to see it and create user mappings for other logins.
you have multiple instances of sql running and you're connecting to the default instance while the database what created on a named instance
you accidentally created the database on another server
you connect to master by default with your software and instead of creating a database the database structure was created in the system database master
I've been working with MS sql for more than a decade and have struggled with issues like these, but in the end I could always explain what happened; if SQL returns it executed a query succesfully id did.
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.
Can anyone tell me the best practice to insert data into a SQL Server database periodically? Say once a day. I get data once in a day from an external source such as a .csv file.
Are there any service programming api that SQL Server supports?
Assuming you're not using SQL Express you can create an SSIS package to do the import, or a BULK LOAD or something like that, and then run the import once a day using a SQL Agent job that uses a daily schedule.
You could also create a Windows Scheduled Task. The task could run a script that connects to SQL Server and runs an SSIS Package, a BULK LOAD, etc. It could also execute a custom program that loads the data.
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
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.