Our dev server has SQL Server 2008 R2 64-bit with SSIS. In order to be able to import XLSX files directly from T-SQL (via OPENROWSET), we installed on the dev server the Microsoft Access Database Engine Redistributable 64-bit. The server already has the 32-bit version installed, so we installed it with the /passive switch.
Since doing that, our existing packages are failing. One of them reports
The step did not generate any output. The return value was unknown.
The process exit code was -1066598274. The step failed.
Just wondering if anyone else has successfully configured their server to be able to use OPENROWSET to XLSX files and also have SSIS on the same server, Or does someone know if this configuration is not possible?
Edit: I should add that the failing packages are run from an SQL Agent job. When I connect to the server's Integration Services Manager via SQL Server Management Studio and run the package (by navigating to the package, right-clicking it and selecting Run Package), it executes successfully.
Personally I've given up on trying to support this scenario - I think the "/passive" install is a hack that doesnt actually work and usually breaks your other install of ADE. I would unintall ADE entirely and then only re-install 32-bit. I would then force all packages run via SQL Agent to execute as 32-bit (as described by Brian).
Following this process gives you some hope of debugging issues as you can open your package in Visual Studio and it will use the same 32-bit driver. You will also use a consistent driver when executing from SSMS (also 32-bit).
Yes there may be a performance hit but SSIS performance is typically limited to some extent by I/O or network speed, not just pure engine throughput.
Yes, it is possible. You have to specify to use the 32 bit runtime in the job step. Open every job step that runs one of your SSIS packages and click on the "Execution Options". Check the box at the bottom "Use 32 bit runtime".
I had "The step did not generate any output. The return value was unknown. The process exit code was -1066598274. The step failed" too.
I found a walk-around for myself: I switched from using xlsx to xls, and the error isn't raised anymore.
Related
I work with Microsoft Access 2016 with a SQL Server 2008 R2 backend. I have used SQL Server Management Studio to create some SSIS package for quick copying of data (right-click DB -> Tasks -> Import/Export).
I was able to create a button in Access to kick off the SSIS package successfully using VBA. I use the Shell function to run the following command:
"C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\DTExec.exe" /F "\\MyPath\MySSISPackage.dtsx". This works on my machine because I'm running my particular instance of DTExec.exe to execute the SSIS package.
I need to set up users' Win10 64-bit computers now so that this process will work for them as well. I don't know if DTExec was installed when I installed SSMS or my local SQL Server Express Edition DB, but the user doesn't need either of these programs. What is the bare minimum I need to install on the users' computers for it to work for them also?
I've done a lot of googling but either the scenario didn't quite fit mine, or I just wasn't understanding what they were talking about. The users will have Microsoft Access only as a start.
Links to download locations would be extra appreciated!
Thanks!
For running SSIS packages in a production environment you must install and license SQL Server. A user who only has Microsoft Access installed cannot run SSIS packages.
You can install and run SSIS packages on your SQL Server (Standard Edition or higher), but not on your clients' PCs.
Once you have credentials all sorted out with DBA team. At min you will need read (select permission) on desired database(s) . Build your ssis in VS2017 locally and test. It will run great I'm sure. And when your ready to deploy you can use steps below.
Steps below outline package deployment mode.
I've created SSIS package, and now I want to create SQL Agent Job. But when I create and run it, I receive the following error:
Which states about version incompatibility. I'm using SQL Sver 2008R2. How can I change its version so that it will be compatible with minimum effort? Interesting, but when I run package in Visual Studio, it runs perfectly.
I've tried to download BIDS for 2008R2, but it doesn't open my project made in another version, and I don't want to create it from scratch.
There is no easy way to achive this (see here).
But you can:
Take 2 machines,
One with 2008 and the other with 2012/2014,
Bring up the 2012/2014 solution in one and start a new 2008 solution in the other,
Use the 2012/2014 version as a script and replicate it in the 2008 system.
You must setup it separatly on 2 machines because SSIS version can overwrite one another during installation and also it can be difficult to get both running on the same machine.
Once we have the same issue and that recommendation (found it somewhere on the internet) was our only way to downgrade to 2008.
Simple question: how does the execution of a ssis package differ when using the SQL Server 2012 Integration Package Utility versus when using the 2012 SQL Server Agent to execute a package? (holding all else constant within deployment- ie using the local file system in both cases)
Thank you.
I am asking because I have an externally referenced dll in my ssis package script that successfully executes with the package utility but not when deployed to the server agent within SQL server 2012 mgmt studio.
If you are sure that the agent service is running on an account that has proper permissions, check to ensure that you are executing the same runtime version for both instances. Your driver may be 64 bit and incompatible with 32 bit runtime and vice-versa.
There is an option in "execution options" of the agent job step that will allow you to select the 32 bit runtime, if needed.
If you are unable to get the "SQL Server Integration Services Package" job step type to work, you can change to using the "Operating system (CmdExec)" job step type and simply build a command using the utility executable (dtexec) and copying the info from the "Command line" tab of the utility. Some prefer this method of executing SSIS packages with the agent as it provides cleaner maintenance of the jobs. Searching the google for this topic will bring up articles like this: http://bi-polar23.blogspot.com/2008/06/ssis-and-sql-server-agent-choosing.html
Hope this helps.
I'm working on a Data Mart loading package in SSIS 2012. When attempting to execute the package in Visual Studio I get this error:
"The AcquireConnection method call to the connection manager Data
Warehouse.ssusr failed with error code 0xC0014009".
When I test the connectivity of the Connection Manager Data Warehouse.ssusr I see that it passes.
When I execute the package outside of Visual Studio using the Execute Package Utility, the package runs.
I don't understand what's going on.
The package also refuses to run using the SQL Server Job Schedule, if that has anything to do with anything.
Making some assumptions here, but I'm going to assume that this is a 32 vs 64 bit issue. To verify, try these two commands from a command prompt (Windows Key, R, cmd.exe or Start, Run, cmd.exe)
"C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\dtexec.exe" /file C:\myPackage.dtsx
"C:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtexec.exe" /file C:\myPackage.dtsx
The first will run your package in 32 bit mode whilst the second runs it in 64 bit mode. This is going to matter as your drivers and any DSNs you've created are going to only be visible in the 32/64 bit world.
Fixing SSDT
Once you've identified which one you need, probably 32 bit version, you'd need to ensure your project is using the appropriate run-time. Right click on your project and select Properties and then navigate to the Debugging tab under the Configuration Properties.
After inverting the Run64BitRuntime value, I assume your package will work from within SSDT.
Fixing SQL Agent
You will need to edit the existing SQL Agent job to change the bittedness of the job step. This will be under the Configuration tab and then under the Advanced tab. Check/Uncheck the 32-bit runtime.
Lies and deception
Observant folks may see that the dtexec offers a /X86 option. Don't believe it. The only way to get the correct bit-ness is to explicitly call the correct dtexec.exe The documentation even says as much but nobody reads documentation.
This option is only used by SQL Server Agent. This option is ignored
if you run the dtexec utility at the command prompt.
I need to build SSIS packages on a build machine, and do not want the overhead of installing SQL Server Management Studio on this machine. A SQL Server 2008 SDK would be ideal, but I could not find where to download it.
The dlls I require are (for example):
Microsoft.SQLServer.ManagedDTS
Microsoft.SqlServer.PipelineHost
Microsoft.SqlServer.DTSPipelineWrap
Microsoft.SQLServer.DTSRuntimeWrap
I could attempt to copy them to the build machine individually, but I would rather just use an SDK if possible.
Where can I get the SDK, or alternatively, what suggestions are there?
You could probably manually copy things about and register then in the GAC, but the client tools are hardly huge, and don't take long to install, so I don't see why they are much of an overhead?
As far as I know there's no other way to get those assemblies.
I think he is trying to accomplish SSIS packages as part of the automated continuous build process. The way i did it was to have an express edition of SQL Server and SSIS on the build machine, use BIDS helper to script the cmd line file for deploying the packages and use NANT to use this script. Hope this helped.
I don't know about SQL 2008 but SQL 2005 SSIS packages are developed in Visual Studio.
Edited:
When you run install for client tools, it's an option to add the stuff to VS.NET, "Client tools" as such can be deselected (end edit)
SSMS can be used to manage them and administer.
What other editor did you want to use...?