A strange thing is happening in SSIS 2008. I have a script component where I set a value for a user variable. The script does what it has to do and then SSIS stops running. All components turn green, so there is no error. The next component that needs to run is the execute process task where I use a CMD command to copy files (XCOPY). If I run the CMD command directly under a command prompt, it works.
Do I neeed to set some properties of the script component in order that it can go through the next component?
No there is no constraint.
Related
I have created a SSIS package that imports CSV files from a folder and writes data into a database. I can run the package locally but when deployed to SQL server and trying to run it via Execute command. The Foreach Loop Container gives a warning as shown in the pic below.
I am currently using a login that is present on the Security\Logins list in SQL server as shown in the pic below:
I have given the user permission to the folder containing the files like show here below .
But I still get error while running the package. Can anyone give me clues that might lead to a solution?
The following error message was constantly appearing for me while trying to run the following OLE commands from AHK:
acc := ComObjActive("Access.Application")
acc.DoCmd.OpenForm("frmSearchLayer",0) ;acc.DoCmd.OpenForm("frmSearchLayer",acNormal)
When closing down my applications I noticed one of my VBA windows was currently open meanwhile being still connected to a COM object from the same database I had been trying to access.
The method to solve my user case:
Check task manager and quit all instances of MSACCESS.EXE
Hi we have a SSIS package that calls an execute process task.
The task accesses a saved sql file in the directory, the agent that runs our task does have permission to access all these files. Yet when the package is executed it hangs at the execute process task, no processes are running but the package still is, all the previous tasks complete successfully until it reaches the execute process task
Hi if anyone is looking for the same problem we came across the answer, the cmd window required user input and therefore could not continue with the process until the cmd process task has finished and it never does.
So in short make sure your cmd process doesnt require user input if you are deploying to SSISDB or it will hang and you cant do anything about it
I have an SSIS package which has a connection to a database. I took the database down to test a scenario, but the package gives me the following error in the output window when starting the package when the DB is offline:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "DBNAME" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
I need to check the connection when the package is run and notify a user, via email, that the DB is down. How would I go about doing this?
I have the code to send the email, I just need to do the DB check when the package is run.
Use a script task. Try to open a connection to your database and if it fails then Dts.TaskResult = Dts.Results.Failure.
A great post about this issue here :
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/7de0216b-3a0a-40ce-8149-f566a05010c9/ssis-check-database-connection-and-if-disconnected-send-email-alert?forum=sqlintegrationservices
Make your DB check occur outside of your package. How is the package run? Scheduled in SQL Agent or kicked off by the user? Instead of just running DTEXEC, first run a script that checks connectivity, i.e. using SQLCMD.EXE.
But really a better way is to run the package as normal then check the SSIS logs afterwards and send an appropriate message. Otherwise you'll be cooking up all different kinds of custom pre-execution checks to run.
I'm no batch script expert but here's an example of a bit of code you can use to test connectivity to a SQL Server and call another batch script if it fails, otherwise run the package with DTEXEC.
SQLCMD -S YOurServer -E -Q "SELECT ##VERSION"
IF ERRORLEVEL 1 (
CALL YourEmailScript.CMD
)
ELSE
(
DTExec /f "\\pathtodtsxfile\file.dtsx"
)
This is not production quality code. I would not recommend calling your DTEXEC in this way, it's just an example.
I finnally got it working. What I did was, create an XML file with the database settings, data source, initial catalog etc. Then added a script task, added some code to read the settings from the XML file and create a SQLConnection and connect to the DB in a try catch. If there is an error send an email, and in the finnaly closed the SQL connection.
But to get this working you HAVE to ensure that you connection has the property 'DelayValidation' set to TRUE. If not the package will fail to aquire a connection before the script task gets executed.
I have a problem with a hang using xp_cmdshell.
The executable is called, performs its work, and exits. It is not hanging because of a ui prompt in the exe. The exe is not hanging at all. The exe disappears from the process list in task manager, and internal logging from the exe confirms that it executed the very last line in the main function
the call to xp_cmdshell does NOT return control in SQL. It hangs on that line (it is the last line of the batch). Killing the process is ineffective. It actually requires a restart of sql server to get rid of the hung process (ugh)
The hang only happens the first time it is run. Subsequent calls to the procedure with identical parameters work and exit correctly so long as the first one is hung. Once SQL is restarted, the first subsequent call will hang again.
If it makes any difference, I am trying to receive the return value from the exe -- my sql procedure ends with:
exec #i = xp_cmdshell #cmd;
return #i;
Activity Monitor is reporting the process to be stuck on a wait type of PREEMPTIVE_OS_PROCESSOPS (what the other developer saw) or PREEMPTIVE_OS_PIPEOPS (what I'm seeing on my current testing)
Any ideas?
Just came across this situation myself where I've run an invalid comment via xp_cmdshell.
I managed to kill it without restarting SQL, what I've done was to identify the process that run the command and kill it from Task Manager.
Assume your SQL was running in Windows 2008 upward:
Under Task Manager, Processes tab. I enabled the column to show Command Line of each process (e.g.: View -> Select Columns..).
If you unsure what command you've run via xp_cmdshell, dbcc inputbuffer(SPID) should give you a clue.
We had the same issue, with SQL Server 2008, also with calls involving xp_cmdshell and BCP. Killing the sql process ID didn't help, it would just stay stuck in "KILLED/ROLLBACK" status.
Only way to kill it was to kill the bcp.exe process in Windows task manager.
In the end we traced the issue down to wrong SQL in sproc that was calling the xp_cmdshell. It was by mistake opening multiple transactions in a loop and not closing them. After BEGIN/COMMIT trans issues were fixed, PREEMPTIVE_OS_PROCESSOPS never came back again.
We actually did eventually figure out the problem here. The app being called was used to automatically dump some documents to a printer when certain conditions happened.
It turns out that a particular print driver popped up a weird little window in the notification tray on a print job. So it was hanging because of a ui window popping up -- but our app was exiting properly because it wasn't our window, it was a window triggered by the print driver.
That driver included an option to turn off that display window. Our problem went away when that option was set.