This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Exception 0x80040154 generated while executing a simple ssis package in MS SQL 2008R2 enviornment
I am trying to execute a simple SSIS package on MS SQL 2008 R2.
I am reading a flat source file, sorting the data based on the ID and write the results in a new flat source file destination.
But when I execute, I get following exception:
TITLE: Microsoft Visual Studio
Failed to start project
ADDITIONAL INFORMATION:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)) (Microsoft.DataTransformationServices.VsIntegration)
How do I proceed from here?
A lot of forums ask to reinstall MS SQL environment but I am not sure if this is the only way to get rid of the exception.
Any better or alternate ways to get rid of this exception?
Thanks.
Try this:
The most common reason for this error message is running a 32 bit dtExec on a 64-bit machine. This post will explain it properly - Quick Reference SSIS in 32- and 64-bits.
Edit: Cached Google link of the article:
http://webcache.googleusercontent.com/search?q=cache:FQN0QKQCleEJ:toddmcdermid.blogspot.com/2009/10/quick-reference-ssis-in-32-and-64-bits.html+&cd=1&hl=en&ct=clnk&gl=au#!http://toddmcdermid.blogspot.com/2009/10/quick-reference-ssis-in-32-and-64-bits.html
There are quite a few misconceptions flying about out there regarding SQL Server Integration Services and 64 bitness. I've had to set more than a few people on the right path in the forums - mostly on one particular setting inside the SSIS packages that is getting misinterpreted. Of course, this information only applies to 64-bit architectures - if you are running a Windows 32-bit OS, you have no choice - your packages will always run in 32-bit mode.
Why would you want to run in 32-bit mode if you have a 64-bit system? Drivers, mostly. I'm not referring to hardware drivers, but data providers. As an example, Excel and some versions of Oracle don't have 64-bit providers. So for the ever-increasing base of 64-bit users, here's the skinny on executing Integration Services packages in your choice of 64-bit or 32-bit mode.
Background
I Can Design Fine, Why Won't It Run?
A little background to start. Business Intelligence Design Studio (BIDS) is a 32-bit application. When you're designing your package, you're using 32-bit facilities - and have no choice in the matter. When you execute your package using DTExec, you have the option of 32-bit or 64-bit operation - but the default on a 64-bit installation is to use 64-bit mode (obviously). However, some commonly used objects in SSIS don't have 64-bit counterparts, and will therefore cause your packages to fail.
Unfortunately, it usually doesn't say anywhere in these messages that the fault lies with 32 vs 64 bits. It's usually something like:
0x80040154 ... Class Not Registered
The AcquireConnection method call to the connection manager XXX failed with error code 0xC0202009
0xC00F9304 ... SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED
The OLE DB provider "Microsoft.Jet.OLEDB.4.0" has not been registered
(I include those sample errors here in the hope that those searching the web may find this article!)
Why Do I Want 32-bit Mode?
The most common reason to want 32-bit mode in an executing SSIS package is the Excel Provider. It's currently not available for 64 bits, and will cause your package to crash. (Office 14 (2010) is reported to have 64-bit support - even though it's not supported side-by-side with 32-bit.) This applies to the other Office providers as well - Access, specifically - and to several other third party drivers and providers (like Oracle). They simply will not work in a 64-bit environment (pre-2010). You may also wish to run Execute DTS 2000 Package Tasks - and those can only run in 32-bit mode as well.
It Depends How You're Executing Your Package
There are many ways to execute an SSIS package - and this is the primary determiner of whether you're running it in 64-bit or 32-bit mode. So pick your execution environment from the list below, and read up on how to force the bitness you desire.
Choosing Bitness Inside Business Intelligence Development Studio (BIDS)
If you're running your package inside BIDS, the setup is simple unless you're using the Execute Package Task or Execute Process Task to run child packages.
The package you currently have open will (by default) run in 64 bit mode. The setting that controls this is a property on the project called Run64BitRuntime. To access this property, right-click on the Integration Services project in your solution explorer and select Properties. Then select the Debugging node in the editor. The default here is "true", which means all the packages in this project will run in 64-bit mode. If you change this to "false", all the packages will be run in 32-bit mode.
Special Note: Execute Package Task
Any child packages executed via the Execute Package Task will run in the same mode as the parent, regardless of the Run64BitRuntime setting of the project that the child package belongs to, regardless of the setting of ExecuteOutOfProcess. This means that even if your child package has Run64BitRuntime set to false in the project you designed it in, it will be executed in 64-bit mode within BIDS if your parent package's Run64BitRuntime property is true.
Special Note: Execute Process Task
The Execute Process Task can allow you to choose 32-bit mode independently of the settings in the parent package, at the expense of running the child package in another process. As with the SQL Agent methods described later, you can specifically identify the 32-bit DTExec to run SSIS child packages in 32-bit mode (see below).
Choosing Bitness With SQL Agent
Instructing SQL Agent what environment you want your packages to run in is simple in Integration Services 2008. SSIS 2005 makes you jump through a few more hoops.
Integration Services 2008
In the Agent Job Step Properties, you'll be using the SQL Server Integration Services Package type of step. If you go to the Execution Options tab, you'll see an option to "Use 32 bit runtime" down at the bottom.
Integration Services 2005
With SQL 2005, you can not use the Integration Services Package type of job step to run an SSIS package in 32-bit mode. Your recourse is to use the Operating System type of job step, and refer to the 32-bit version of DTExec specifically in the command line that you use, and manually specify arguments to DTExec.
Hurdle #1 - Finding the 32-bit DTExec
Finding the executable shouldn't be difficult. In a standard 64-bit installation, the 32-bit DTExec.EXE should be located in the "\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn" folder. It's plainly called "DTExec.EXE", and doesn't identify itself in any way as a 32-bit app - you'll have to "know" it is by it being located in the 32-bit folder. (Or you could try to execute it and watch Task Manager.) If you've installed SQL to a non-standard location, you may have to hunt a little. If you can't find it at all, you may not have installed the 32-bit components on your 64-bit machine. During the install of SQL Server, if you only selected "Integration Services" and didn't install "Business Intelligence Development Studio" OR "Management Tools - Complete", then you won't have the 32-bit DTExec installed. You'll have to run SQL Setup, and install one of those options.
Hurdle #2 - Determining the Command Line Arguments
Next, you need to determine the command line parameters you need to operate DTExec from the command line. You could read through the documentation and attempt to determine the arguments and settings by yourself, but I would recommend you use the power of the included GUI tools. Both the IS Job Step in SQL Agent, and the DTExecUI tool provide a GUI to configure an SSIS package run. On the last page of the GUI, it very helpfully places the exact command line arguments needed to run DTExec, based on all of the configuration options you've chosen on the ten or so other tabs of the GUI. Leverage that! Set up your package execution using the GUI, then copy the arguments off that last page.
Precompiled Scripts
This is only an issue in Integration Services 2005 - the dev team completely fixed this issue in SSIS 2008. There is a "Precompile" option on Script Tasks, which is set to "true" by default. If this has somehow been set to "false", your packages may not execute in a 64-bit environment.
32-bit ODBC Drivers
There is also one other oddity with using 32-bit ODBC drivers in Windows - at least in Server 2003, 2008, Vista, and Windows 7 64-bit OSes. The first step to using those drivers is to set up a DSN to handle storing the server name and other particulars. In my experience, the natural first place to start is by opening the "Data Sources" applet in the Control Panel. That's mistake #1 - because that applet only manages 64-bit drivers. You won't see yours listed at all. The next step is to poke around and realize that there's a "Data Sources (32-bit)" applet there in the Control Panel as well. That's mistake #2 - but not your mistake. In my experience, this icon leads to some odd hybrid 32/64 bit management utility. It definitely did NOT manage my 32-bit sources. If you fire it up, then look at the processes tab in Task Manager, you'll see a process labeled "odbcad32.exe"... but you'll notice that it doesn't have the "*32" after it denoting that it's a 32-bit app. Whatever it's attempting to manage, it's not the 32-bit ODBC drivers. What you need to do is navigate to another odbcad32.exe that's sitting in your SYSWOW64 folder. That ODBC data source administrator truly does manage 32-bit drivers, in a 32-bit process.
References/Resources
Most (if not all) of this information is also distilled in an MSDN article: 64-bit Considerations for Integration Services. If you find other useful articles, pointers, or mistakes in the above, please post a comment.
Some other very useful articles:
How To: Run a Package, MSDN
64-bit references within an SSIS Script Component by Michael Entin, Microsoft SSIS Dev.
64-bit Considerations for SQL Server Integration Services by Douglas Laudenschlager, Microsoft SSIS Dev.
Where is my app.config for SSIS? by Darren Green, SQL Server MVP.
Oracle Driver Configuration in a 64-bit environment by Rob Kerr
Importing data from 64-bit Excel in SSIS by Hrvoje Piasevoli
32- and 64-Bit Connectivity from the Same Machine by SQLCAT
Posted 18th October 2009 by Todd McDermid
Related
I'm having an issue with Visual Studio 2005. I'm writing an application in VB.net using Microsoft.ACE.OLEDB.12.0. I've got a couple of applications using that provider already and they all run fine. I can Publish them again or run them in the IDE and they work fine. When I try to run the new application I get the message that "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on local machine. I've started the application over several times with no change. Under Data Connections inside VS, I can open the database and see the tables, views and procedures. But it still gives me this message. I've tried to reinstall the driver and nothing changes. I've uninstalled in and reinstalled it, no change. Any ideas?
Access drivers are, as far as I know, bit-specific. If you have the 32 bit driver installed and your compile/run your app in x64 it will fail to find the driver. Match the bitness of your project to the bitness of your installed drivers (or cycle all the options). Remember that the Prefer32bit setting can influence the resulting bitness chosen in an AnyCPU situation (e.g. if you have 64bit drivers, and have AnyCPU+Prefer32=Y then you may encounter a fail)
I have seen other posts about this topic where some of the suggestions lead people to check the ProtectionLevel to DontSaveSensitive. I have made sure that is set to DontSaveSenistive, as well as I have checked permissions and made sure where the files/dtsx files are getting called from have ample permissions set for the service account which owns the SQL Agent.
The odd thing is this process was working fine until i went into one of the previous dtsx files and had to update a datatype precision to go from a limit of 1 character to 30 characters. That was literally the only change made to the process, but now I am getting this error. I have gotten this error before, which is when I was set on the path to checking protection level and permissions/ownership. For some reason it went away and began working when i made those changes. None of that stuff (permissions/ownership) is incorrect this time around yet I am getting that same error.
Another weird thing about the process is that it is only the last step which is failing (the FTP step.) When I try to go in and execute the psftp.exe and put in the command which is being passed normally through SSIS execute process task step, the psftp.exe is telling me that the port number is incorrect..yet when I test connection on the connection manager inside VS with the exact same port, it says connection successful.
This error is vague and confusing!
I would love some guidance on some more things to try.
thank you !
SSIS tooling and version
SQL Server 2008 and 2008 R2 can only be edited using Visual Studio 2008 which has the Business Intelligence Design Studio templates installed. Those can only be acquired by having the physical SQL Server iso handy. Developer edition will work, but you need some form of licensed media to get BIDS working.
Visual Studio 2013 is going to attempt to upgrade 2008/R2 to the internals for a SQL Server 2012 installation. There is no going backwards/downgrading once this is done.
Any tooling (dtexec, dtutil, etc) you use must be from the same version otherwise, the first thing the binaries do is update the package to match that version. For execution (dtexec), each time you run a package, there is a delay as the original is upgraded in memory to match and then execution begins (assuming all goes well). It sounds like it's not based on
The package failed to load due to error 0xC0010014...
For deployment (dtutil), you only pay the price of upgrading once and then it's upgraded forever. Which probably isn't what you wanted. Be aware that tools like Visual Studio and SSMS "know" which version of tooling they are associated with so deploying from SSMS 2016 can result in the binaries for SQL Server 2016 SSIS upgrading your 2008 package to 2016 format and then attempting to deploy the now upgraded bits to your 2008 box. It's all very frustrating and not intuitive.
From your comment "In the 2008 version, the play button is greyed out..." That indicates you have opened a File in Visual Studio that is an SSIS package. Visual Studio will open it and paint all the icons on there but it can't actually run a package unless you have an Integration Services project open (and have the BI templates installed).
Assuming you have source control, you can rollback the change that broke everything and try to edit the package properly.
Execute process task
You have an Execute Process Task that is invoking psftp.exe and it's generating a 1 versus a 0. Is that bad? Based on previous workings with SFTP clients, they're rather picky so running it as me on production would fail since I didn't have whatever bits associated to my domain account but the service account had all the right things in their profile and it would run just fine - same machine, same package, just different user.
I'm using the Crystal Report 10 viewer ActiveX control in an Access App I've written. Works great in Office 2003 on 32bit versions of Windows. The problem arrises when I try to run the program in 64 bit Windows (with 32bit Office). I get the following error:
Run-time error '429': ActiveX component can't create object
I get this error on the following line of my VBA code.
Set rdApp = CreateObject("Crystalruntime.application.10")
How can I get this to work in 64bit?
I don't have any specific experience with Crystal Report, but I do have some experience with installing components on a 64-bit Windows environment that were intended for 32-bit Windows, so here are some general suggestions of things to try:
Before installing, try loosening the security privileges - I have Windows Server 2008; on this OS, they're under Start | Administrative Tools | Local Security Policy. Many old installers are thwarted by these controls. You'll want to return them to their defaults after the install.
Make sure that you run the installer with admin privileges (right-click; run as Administrator).
Examine the installation log for Crystal Report - it may indicate a failure registering a component. In one instance, I was able to get the installation working by running the command to register the failed component manually, on an administrator-privileged command line (the command was in the log).
If acceptable, try to create a Windows Virtual Machine running a virtual Windows XP, and try the installations there (this might be a bit tedious, due to your need for MS Office).
Take a look at VMWare's ThinApp - this is intended for packaging applications for administrators, but this was the solution we ended up using to shield one of our 32-bit apps from Windows 64-bit perils
Hope this helps; we struggled for awhile trying different things to get our legacy apps working on a 64-bit environment.
Best practices or tools for installing a SQL Server database
I have a SQL Server database designed with the SQL Server GUI database editor/Visual Studio.
What is the best way to "install" that database on other systems. Said another way how should I ship this thing?
I know I can save the scripts and set the primary/foreign keys with T-SQL but I suspect their is something better. I guess you could have people restore from backup but that does not seem very professional.
What other choices are there and what are the pluses and minuses?
For it to look professional make a small setup program.
You currently have sql scripts that you use to create your db.
Make yourself a small xml file that contains the path to your scripts.
Create a small c# library that will connect to the db server, and run those scripts.
You can test this outside of the setup, in visual studio, then add it to the setup like this.
To do this from your setup all you have to do is put the xml file in a component so it is deployed,
And create a custom action in your setup, that will call your C# lib, read the xml and run the scripts on the sql server to create your db.
Also, from a setup program it's easy to set a registry key to identify the version of the your db that you just installed.
The minuses and pluses: It's a bit of work to start with, but with this you'll have all the ground work done to handle upgrades automatically later on, to do so, just add an upgradeScript section to your xml, an attribute called version for each upgrade script, and simply compare it against the version of the db you have save in the registry. The advantage is this way it can easily scale with your project.
My previous answer is mostly to keep full control on the deployment and upgrades.
I have searched for more built-in and streamlined solution that goes along with the DB designer mode you have used.
I found that in the version Studio 2005 Team Edition for Database Professionals of visual studio there might be deployment features.
Build and Deployment
You've seen that you can generate a
T-SQL update script manually via the
Schema Comparison tool. However, as
part of the build process, DB Pro
edition can generate a complete script
for deploying your database project.
This deployment script can do either a
complete build or an incremental
update. The build process can even
consolidate all of your pre- and
post-deployment scripts into one
complete deployment script. You can
deploy the script via the Build |
Deploy Selection command right from
within Visual Studio 2005. Under
project properties, you will find a
number of options to control and
adjust the build process. The Build
tab contains the core settings, such
as Target connection, Target database
name, and Block incremental deployment
if data loss might occur. You'll note
there is also a Build Events tab that
you can use to type pre- or post-build
event commands. DB Pro edition uses
MSBuild for its build process and
supports integration with Team Build
if you're using Team Foundation
Server.
I de-installed SQL server 2005 express some time ago when I installed SQL server 2008 express.
Doing that install required windows installer 4.5.
Now I discover a reason to have SQL server 2005 express again.
(to reconnect to the outlook Business Contact Manager which requres it to connect to the default MSSQL\MSSMLBIZ database)
However, when I install any version of SQL server 2005, it fails for all the important things, like the database engine, with the message that I should upgrade my windows installer to a newer version.
I'm interpreting this as the SQL 2005 installer is experiencing failure and is presuming it is because the installer version is incorrect, and presuming the version is too previous.
But I suspect the version is too subsequent.
Any way out of this?
The error messages are produced by MSI-based installers are notoriously misleading (most installers silently swallow a lot of error conditions and present one single generic error message.) The best thing you could do is sift through the log files created by the SQL Server 2005 installer (IIRC, they're dumped into the %TMP% directory.) That will certainly provide more information.
You could try to uninstall the KB942288 package (Add/Remove Programs, make sure the Show updates checkbox is checked, and locate the corresponding entry.) Here's the corresponding Microsoft KB article as well. No guarantees as to what this will do to your system though, especially since you've certainly performed a lot of install actions since you installed 4.5.
You could also try one or more of the generic MSI debugging techniques described in KB 555175.