My SSIS Script Task works fine when is executed in debug mode, but when I execute package from a SQL Job, it doesn't: it doesn't find the file, even if the file exists.
The package and the file to found are on the same server; the SQL DB is on another one. I use the UNC path for finding file and I gave the right permission to the users defined on the file folder.
Related
I have a package on SSIS that executes a .BAT file that consequently executes a PowerShell file, which brings the file metadata from a folder, generating a CSV file.
I already granted access to the folder for the SQL Server Agent user, but it didn't work.
When I run the package on SSIS, it works correctly! However, if I execute the same package through a JOB in SSMS, it ends the step, but the .BAT file was not executed, or if it was, the Powershell file did not, because after the execution the CSV file is "1kb", no data.
Am I forgetting something?
SSIS package (portuguese language):
[EDIT 1]
A strange thing that I noticed, was that we have 3 packages scheduled by SSMS, but only one of them that doesn't work, which is the one mentioned in the question. But I can't find out why or what the difference is to others.
2 packages extract information from Sharepoint and work on SSMS, but this other package that extracts metadata from files does not.
Check the job step's "Run As" value, which is a "Proxy" (visible in the Object Explorer in SSMS.
Open the Proxy (SQL Server Agent >> Proxies >> SSIS Package Execution). It will list a Credential Name.
Open the Credential (Security >> Credentials). It will list an Identity. That's the user whose security needs to be configured.
Open a cmd window and run runas /user:<userGoesHere> cmd and enter the password when prompted. See the documentation of runas here
Now, it opens a second cmd window which runs under this user used in the SQL Server Agent. Execute your batch file and see if you'll catch any error.
Also, the process you're running may require the user to have Log on as a batch job permission. Run secpol.msc from an admin account and add this user to this permission.
I have an SSIS package that uses a configuration file which only contains the InitalCatalog and ServerName for an SQL Server database connection. If the configuration file is missing, the SSIS package produces a warning that the file is missing but carries on executing.
If the database connection manager in the package is configured with a different Server Name (ServerName in the configuration file) and Database Name (InitialCatalog in the configuration file), the package will run and use the "wrong" database, i.e. the one in the package's connection manager, not the one in the configuration file.
I have got round this by writing a Script task that checks for the existence of the configuration file and executes the line Dts.Events.FireError(0, "Script task", "Missing Configuration File", String.Empty, 0); if the file is missing. This results in an error being returned to the package and it terminates.
Surely, an SSIS package should terminate if it can't find its configuration file?
Apart from my workaround above, is there any other way to force a package to error and exit if it can't find its configuration file?
Thanks,
Kevin
I have an ogr2ogr batch file that reprojects SQL data into a new SQL Server table.
It works fine when I run the bat file manually but it fails if I run the bat file via a SQL Server stored procedure. I have given the gdal folders SQL Service permissions and xp_CommandShell is also enabled. I'm using
EXECUTE xp_CMDShell 'blah'
in the T-SQL script.
For some reason the ogr_MSSQLSpatial.dll causes it to fail.
ERROR 1: Can't load requested DLL: Z:\BroadSpectrumSQLTreeExtract\ogr2ogr\gdalplugins\ogr_MSSQLSpatial.dll
If I remove this dll the script runs via SQL but it means I need to add extra commands that the dll must take care of, such as setting source coordinate system. I haven't managed to get it working 100%. The furthest I got to was producing the reprojected table but the geometry field is empty.
The DLL does contain SQL commands to the system tables. Could this be a SQL Server security issue stopping it from working?
I again had this problem with another ogr2ogr bat while executing with SQL. If I put the bat in the same folder as the dll's it works fine.
I'm new to SSIS and stuck with a problem and hope some of them would have already gone through any of this.
Task:
Copying files from a remote server to a local machine folder using File System task and For each loop container.
Problem:
The job executes i.e. files are getting copied successfully when I execute from the SSIS designer but when deployed the project on the SQL server instance it isn't copying any files in fact the target folder is totally empty.
I'm not understanding this strange behavior. Any inputs would be of great help!
Regards-
Santosh G.
The For each loop will not error out if it doesn't find any files.
The SQL Agent account may not have access to read the directory contents.
Check is your path a variable - is it being set by a config or /SET statement?
Can you log the path before starting the for loop?
Can you copy a dummy file and see can SSIS see this file?
How are you running the job - cmd_exec() can give spurious results with file I/O tasks
The issue was related to the user authorizarions of the SQL Server agent service.
When I execute the job from SQL Server it uses agent service and for that agent service you need to assign a service user who has access rights to the desired file path.
I have a batch file to open a spreasheet and run the auto open macro. This work . Putting the batch file on a sql server agent job, again it works but the job never seems to end . Any ideas why ?
Code for batch file
call C:\Imports\Account.xlsb
exit
code for sql server agent
C:\Windows\System32\cmd.exe /c "C:\Imports\Test\OpenExcelFile.bat"
I'm not sure why you would need to run cmd.exe to run a batch file. You should only need to specify the file name name in quotes while using an "Operating system (CmdExec) job step. The step should use the following code:
"C:\Imports\Test\OpenExcelFile.bat"
If this doesn't work, then try running the batch file from the xp_cmdshell stored procedure. Here's the code you would need to execute:
EXEC master.dbo.xp_cmdshell 'C:\Imports\Test\OpenExcelFile.bat';
GO
This could be called by a Transact-SQL script (T-SQL) job step.
Are you calling this in a SSIS package? The post was tagged as SSIS, but you never mentioned in the post that you tried to call this from a SSIS package. If this is a SSIS package, then are you able to run the SSIS package successfully in BIDS? If you are running this from BIDS, then you shouldn't need to call the cmd.exe file. There is an Execute Process Control Flow task that you could use that does not require running a batch file from cmd.exe. If you are not using a SSIS package, then can you remove the SSIS tag?