I have made an SSIS package that uses the Excel source to extract data from an Excel 2003 file and inserts it into SQL Server. When executed on production machine it gives and error of 'productleveltoolow'. Excel is not installed on the server. Can this error be due to this reason?
'productleveltoolow' means the server does not have SSIS installed.
http://blogs.msdn.com/michen/archive/2006/11/11/ssis-product-level-is-insufficient.aspx
Do you use a 64 bit operating system? In that case you have to use the 32bit version of SSIS due to the fact that there is no 64bit driver for Excel (Jet engine), and there never will be.
I do not think this is the answer to your question, but you need to keep this in mind.
/Håkan Winther
Related
I'm trying to build an import utility for users to import Excel files into SQL Server 2017.
I've hit the 32bit/64bit roadblock with OLEDB providers.
I'm using a 32 bit Microsoft Access front end, and SQL Server is 64 bit. You can't install both 64bit and 32bit ACE OLEDB providers. Microsoft have even built two different import/export wizards for this problem (one for 32bit, one for 64bit).
Does anyone know a way around this problem, or an alternative method of getting Excel data into SQL Server from a Microsoft Access front end that doesn't rely on OLEDB providers? (saving as a text file is not an option, neither is installing 64bit Office)
Thanks
i think BULK INSERT will help you solve this. See here link
We supply an Excel Add-In which you can use to build solutions to let end users insert and update data in SQL Server directly from Excel.
You can download a fully functional trial here.
Disclaimer: I am the founder of the company.
You can use SSIS package to load EXCEL file into SQL Server. You can have data flow task and have Excel source and Sql server target.
UPDATE
If you are having 64 BIT, 32 BIT related issues, you can execute SSIS package in 32 bit runtime using dtexec.exe.Read more dtexec
You can execute SSIS package from C#
Generally, Servers and Desktop machines will have 32 BIT OFFICE drivers installed already. So, you should not have issues. If required, you would need to run dtexec.exe in 64 BIT. You can download dtexec.exe accordingly.
More information on using dtexec.exe
I am new to ssis.I have a task where i need to import data from table to excel and table contains nearly 500K records.My problem is when opt for excel file destination and create a connection manager and use excel 2007 then i cannot see tables under name of excel sheet.when i tried to install access database engine
i struck with error saying you cannot install 32 bit because you have installed 64 bit of Microsoft products.Please suggest
Here is a link to your access database engine driver. You can choose 32bit and 64bit. Remember to reboot.
Microsoft Excel ACE Driver
You could also choose a flatfile destination as CSV instead, and then load that in Excel. That is easier imo.
I'm using Visual Studio 2015 to create a simple SSIS package. The data source is a DB2 database, and I'm using an ODBC driver on my workstation to connect to DB2. The target is SQL Server 2014.
The package runs fine locally, but whenever I run it on the server, I'm having trouble with the ODBC data source. The driver on the server is the exact same one with the exact same name as the one on my workstation.
To get the package into the server, I've imported the dtsx file into SSIS in Stored Packages. I've also tried to deploy the project to the Integration Service Catalog, but I get one of these failures related to the ODBC source when doing so --
The version of ODBC File Source, clsid {xxx} is not compatible with this version of the Data Flow.
The component is missing, not registered, not upgradeable, or missing required interfaces. The contact information for this component is "ODBC Source;Connector for Open Database Connectivity (ODBC) by Attunity; Attunity Ltd.; All Rights Reserved; http://www.attunity.com
I've also tried using a file based ODBC source instead of a system one with that file in a shared folder on the server. Again, it runs fine in VS but not on the server.
I've looked at the dtsx file (xml based) and I suspect that there is a conflict with the DTSID for the ODBC driver. I'm not sure how that works but it seems like that ID would be unique for each computer and that SSIS is getting is trying to use the workstation's DTSID on the server.
I'm a bit new to SSIS and Visual Studio so I'm hoping I'm assuming there is a straightforward way to run packages developed on a workstation at the server without these hangups. I just can't find anything specific to this problem anywhere.
We do not have VS or SSDT installed on the server.
EDIT: I added a second sentence in the 2nd error message above. It refers a connector provided by Attunity, which is something I don't understand. The ODBC driver installed on the system is from Data Direct. The CLSID returned in the error message is also associated with an Attunity connector in the server's registry.
There are no ODBC drivers from Attunity showing up in either of the ODBC managers, so it's possible that these are somehow part of a default install or were installed when our server used to have SSDT and VS installed directly on it and were never uninstalled. Or, something else?
I have resolved this issue by changing the Deployment Target Version of Integration Services project in VS in my case from SQL Server 2017 to SQL Server 2016 (the target SQL version). Hope this helps. Old quesition, but came up first in google when I tried to solve my problem.
In my case this issue was caused by deploying an SSIS project to a 2016 server using SQL Mgmt Studio 2017. Once I redeployed using SSMS 2016, it resolved the error.
VS or SSDT by default uses 32-bit drivers, so check there is option when you execute for 32-bit. Or install both 32-bit and 64-bit driver and create ODBC with same name.
This is what i do usually for ODBC connections in SSIS -- create connection in both 32-bit and 64-bit.
So create one with
C:\Windows\SysWOW64\odbcad32.exe (32-bit)
and one with
C:\Windows\System32\odbcad32.exe (64-bit).
I had this same problem when executing my package in SQL Server Agent. I resolved it by turning on the Execution Options "Use 32 Bit Runtime" flag in the agent step. Drove me nuts for a few days, hope this helps.
check the version of your solution vs the SQL version of where you are deploying. I had this issue and matching up versions fixed the problem. My solution was 2017 but the SQL box was 2016. I had to change the solution to 2016. cheers!
In my situation I was having this error and I switched to using the 32-bit version. My initial test worked, then I redeployed using a the project I was working with and I got this error again, even though I had switched Execution Options "Use 32 Bit Runtime" flag.
It ended up that I was having problems with my ODBC Data Source. I was using IBM Informix driver and it was having an issue with the chosen locale. I changed it to use the server's specific local and tested its connection. That then worked and my SSIS package worked on the server.
In another situation with this same Informix driver, I had the database name, slightly incorrect and that gave me this same error.
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.
I have an SSIS package that uses an ODBC connection to a Progress database as a source using a 32-bit ODBC driver. This package runs perfectly within the confines of BIDS. However, when I run it using the SQL Agent, it fails with the error:
The specified DSN contains an architecture mismatch between the Driver
and Application.
I know that this is probably a result of it wanting a 64-bit ODBC driver for that connection, but I can't seem to get the 64-bit driver to work correctly within BIDS. Is there a trick that would allow me to use the 32-bit driver within SQL Agent and move on with my life?
I found my answer. Under the Execution Options in the Job Step Properties there is a checkbox at the very bottom --- "Use 32-bit Runtime." Simple enough!
Thanks for your help.
BIDS = your local box, 32 bits
SQL Agent = your server, 64 bits
is that right?
If yes, you will really need the correct driver.
This is from BOL:
Be sure to note that if you develop a package in a 32-bit environment
and want to run the package in a 64-bit environment, the connection
managers need to be 64-bit compliant. Some connection managers such as
Excel work in a 32-bit environment only.
Yuo can call 32bit DTEXEC directly with CmdExec. Point at 32bit DTEXEC.
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\dtexec.exe