I have a SSIS package which reads an Excel File (Data Flow Source) and transfer the data to SQL Server using OLEDB Destination Data Flow Item.This package is executed by .Net Application using the SSIS Object model. The package stored in a file system within the application subfolder.
The package works fine on my development/test machine both.Both these machine has win2k3 32bit. The SSIS was build in BIDS 32bit Environment.
When I deploye this application on production machine which has win2k3 x64 standard edition i get the error
An OLE DB error has occurred. Error code: 0x80040154. An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC0202009.
component "Excel Source" (630) failed validation and returned error code 0xC020801C.
I have read in other posts that setting the Run64BitRuntime property of the project(during design time) solves the problem when running it from the BIDS.
How do i set this property through SSIS object model.
Here is the part of the code that executes the package
_application = New Application()
_package = New Package()
_package = _application.LoadPackage(packageName, Nothing)
_updateResult = _package.Execute()
Thanks
Masood
The Run64BitRuntime property only applies to the packaged running inside of BIDS. There is no need to set this property when running outside of BIDS.
I believe that you issue is that when running in code, the package is executing in 64 bit mode, however, Excel does not support this. In order to make this work you will need to shell out to launch the 32-bit version of DTExec.
Related
I'm trying to connect to DB2 with function apps, but I have problems with DB2 dlls.
I receive this error during the debug of my function app, using latest versions of IBM.Data.DB2.Core nuget packages (1.3.0.100) :
{'Unable to load DLL 'db2app64.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)'}
This line generate the exception:
using (DB2Connection conn = new DB2Connection(str))
The specified dll is present in folder, so someone know what should be the problem?
This could happen if you have the IBM.DataDB2.dll file lying around in directories other than the DB2 client install location. This could have happened without your knowledge where Visual Studio copies the necessary dll into the bin directory of the project.
Same question or the duplicate of IBM.Data.DB2.Core throws exception in azure function app
I'm trying to run a local SSIS package from a C# console application. I've built both the package and the application using .Net 4.5.1 in VisualStudio 2012. When I say "local" I mean the SSIS package hasn't been deployed to a SQL Server; I'm just trying to call the .dtsx file from the file system. The SSIS package runs fine from within VisualStudio. Here's my code:
string pkgLocation = #"C:\Users\06717\Documents\Visual Studio 2012\Projects\RMA_Data_Cleanup\RMA_Data_Cleanup\";
string pkgName = "Package.dtsx";
Application app = new Application();
Package pkg = new Package();
DTSExecResult pkgResults = new DTSExecResult();
try
{
pkg = app.LoadPackage(pkgLocation + pkgName, null);
There's more after this, obviously, but the problem comes with the app.LoadPackage line. When I try to run it, this exception gets thrown:
The package failed to load due to error 0xC0011008 "Error loading from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information can be stored.". This occurs when CPackage::LoadFromXML fails.
I've googled this error message, and I haven't found anything that seems to apply to my case. One thing that occurs to me is that maybe I'm calling the wrong dtsx file. There's another one in the obj\Development folder. I've tried calling that one too, but I get the same exception. Am I calling the right file? Is there something I need to do from within Visual Studio, other than build the package, before I can do this? (pkgResults = Success, BTW)
I've been attempting to create a table through my machine's Azure storage emulator. I can recreate the problem with a very simple program that uses only WindowsAzure.Storage nuget version 6.2.0 :
using Microsoft.WindowsAzure.Storage;
namespace StorageEmulatorTest
{
internal class Program
{
private static void Main(string[] args)
{
var cloudStorageAccount = CloudStorageAccount.Parse("UseDevelopmentStorage=true");
var cloudTableClient = cloudStorageAccount.CreateCloudTableClient();
cloudTableClient.GetTableReference("JohnnyTest").CreateIfNotExists();
}
}
}
After 25 seconds, this will throw an exception of type Microsoft.WindowsAzure.Storage.StorageException with only this message:
The remote server returned an error: (500) Internal Server Error.
I have attempted:
Ensuring my WindowsAzure.Storage nuget package is the latest version (6.2.0).
Re-installing the Azure SDK for VS2015 2.8.1 (and ensuring that it's the latest version)
Stopping, clearing, initing the Azure Storage Emulator through the Azure Storage Emulator command line tool (seemed to work fine, no errors)
Reading the web response's stream through the exception's ".InnerException.Response.GetResponseStream()". This fails with an exception that states "Stream was not readable".
Restarting my machine (desperation kicked in)
My bag of tricks is running low. Has anybody encountered this issue?
I solved it. I had to completely wipe out my existing local storage emulation instance. Using "AzureStorageEmulator.exe clear" or "AzureStorageEmulator.exe init" was insufficient. Even uninstalling the Azure SDK was insufficient.
I started by stopping the storage emulation:
AzureStorageEmulator.exe stop
AzureStorageEmulator.exe clear
AzureStorageEmulator.exe init /forceCreate
That last command errored and indicated that it could not create the database.
Then I deleted (actually, I renamed them) these remaining files that comprised the database behind the azure storage emulator:
C:\Users\[Me]\AzureStorageEmulatorDb42_log.ldf
C:\Users\[Me]\AzureStorageEmulatorDb42_log.mdf
Finally, I started the emulator back up
AzureStorageEmulator.exe init /forceCreate
AzureStorageEmulator.exe start
Success!
I'm unsure what got me into the situation, but my best guess is that this was caused by a recent upgrade of the Azure SDK.
I think in many cases Johnny's answer will solve the issue.
In my case this also did not work, because AzStorageEmulator did not create the database AzureStorageEmulator510 (database instance (localdb)\MSSQLLocalDB) and also not the tables within.
So I used SSMS to create database AzureStorageEmulator510 from scratch,
then I found that an older version AzureStorageEmulator57 was still on my PC, so I attached it (you can find the databases in C:\Users\YOURACCOUNT) - extracted the database structure to a SQL script and ran it for AzureStorageEmulator510.
After that, I started the emulator and created a new blob container using AzStorageExplorer.
The Error 500 seemed to occur because that database (and structure inside) was missing and could not be recreated by the CLI command AzureStorageEmulator.exe init /forceCreate.
Other things you can check (possible issues):
It can also be AzStorageEmulator can't access its database. One of the reasons (and how it can be fixed) is described here.
After installing a newer version of the instance (localdb)\MSSQLLocalDB, it can be that the related database is not attached. This will result in a strange error like
Cannot open database "AzureStorageEmulator510" requested by the login. The login failed. Login failed for user 'YOURACCOUNT'.
If that is the case, you can fix it by simply connecting to localDb via SSMS, then attach the database: Right-click on databases, select Attach... in the context menu, then in the dialog, add the database file (located in C:\Users\YOURACCOUNT).
I developed a pretty straight forward SSIS package (in VS2005 w/ .Net Framework V 2.0.50727 SP2) that gets a list of users to email, starts a for-each loop container and then executes a script task to retrieve user specific data and email it out to the user. When I run it on my dev box everything works great and runs as it should. However when I deploy the package to our production server running (Microsoft SQL Server 2005 - 9.00.5000.00 (X64) Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2) ) the task fails.
The original error message is:
Executed as user: xxxxx. Microsoft (R) SQL Server Execute Package Utility Version 9.00.5000.00 for 64-bit Code: 0x00000009 Source: PackageName Description: The task cannot execute in 64-bit environment because the script is not pre-compiled. Please turn on the option to pre-compile the script in the task editor. End Error ... Error DTExec: The package execution returned DTSER_FAILURE (1).
After researching that extensively the interwebs suggested that I try:
running the package in 32bit by changing the execution property in the SQL job and by changing my RunIn64BitMode property from true to false
which fails because " Option "/X86" is not valid."
install the Microsoft Hotfix
which doesn't apply since I am already running on SP2
So after more research I find that I need to turn on "Please turn on the option to pre-compile the script in the task editor." SOURCE: ssis-dtsx DOT blogspot DOT com/2010/03/cannot-execute-in-64-bit-environment.html
Which entails:
Make sure that each script task has PreCompile = True
Open Script Task Editor, switch to Script tab and make sure that
PrecompileScriptIntoBinaryCode = True
Click on Design Script to open code editor (Visual Studio for Applications) and then choose it using File > Close and Return (VSA will recompile and store binary code in the package).
Build Project and copy to target location
However when I execute the package I immediately get the error:
Executed as user: xxxx. ...0.5000.00 for 64-bit Code: 0x00000008 Source: PackageName Description: The task is configured to pre-compile the script, but binary code is not found. Please visit the IDE in Script Task Editor by clicking Design Script button to cause binary code to be generated. End Error Code: 0x00000008 Source: GET PO infor and Email Description: Script could not be recompiled or run: Retrieving the COM class factory for component with CLSID...
So my final step was to turn DelayValidation property from False to True in the SSIS pkg, go into the design script to cause it to be rebuilt, then redeploy, and rerun and I still get the same error.
On searching the error I am directed to Microsoft HOT FIX which suggested that I download another hotfix.
I have not yet downloaded the hotfix, and would prefer not to if I can avoid it (our OPs team doesnt like running hotfixes mid day on production servers).
Go to the package, open the script component, then within Visual Studio (while looking at the code) click on BUILD. This will compile the package, if there are no issues preventing it from compiling. Then SAVE, go back and ensure that you click on "OKAY" and not "cancel", if you click on cancel then the whole thing reverts back.
I went through the process of creating the server and client ODBC objects in my computer to a Cobol database and I named the client PARSECCLI.
I tested the connection and it works. I can get datasets through Microsoft Query (I can't get Sql Server Management Studio to connect to it as a Linked Server or anything, but that's a separate question).
I can also create, through Visual Studio's wizard, a Datasource connection to it and the connection test succeeds. It creates this connection string:
Dsn=PARSECCLI;uid=.;codepage=1252
However, if I try to create an OdbcConnection to that string and open it - my end goal is to be able to run queries on the database and pull datasets from it - I get this:
System.Data.Odbc.OdbcException (0x80131937): ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application
if I take advice from This question and change my connection string to this:
OdbcConnection dbConnection = new OdbcConnection("DRIVER={Relativity Client};ServerName=192.168.0.109.1583;DSN=PARSECCLI;UID=.;codepage=1252"); //The local IP I set to static when I created the client and server odbc Data Sources.
I get:
System.Data.Odbc.OdbcException (0x80131937): ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Should I be using a different sort of Connection type or am I missing something from my connection string/s?
The ODBC Administrator (odbcad32.exe) program comes in two versions on 64bit systems. The default one (the one present in the Administrative Tools) is the 64bit version and creates DSN names usable by 64bit programs (or AnyCPU programs that runs on 64 bit OS).
If you want your DSN usable by a 32 bit program create it with the ODBC Administrator available in the c:\windows\SysWOW64 folder.
Of course your application should use the appropriate Target CPU through BUILD -> Configuration Manager, Active Solution Platform.
Sadly I have no answer for the second issue but I hope that the first one is enough to allow you continue on your program