I have a winforms application that makes use of Microsoft.SqlServer.ManagedDTS to load and execute an SSIS package. When running locally in debug and when installed the package runs fine, when installed on a dev server the package runs fine. When deployed onto a live server I get the following error.
I'm running out of ideas of what to check, I don't want to move away from using this method of executing my package as this adds further complication to the application that we really don't want to introduce. Any thoughts?
For clarity I have checked:
SSIS is installed and is the same version (Windows/SQL Server 2008)
I added the following app.config key following some google searching useLegacyV2RuntimeActivationPolicy="true"
Tried compiling as a 32-bit and 64-bit application
Ensured that the DLL is registered in the GAC on the target machine
All permissions are the same across the two boxes
The extract of source code that is throwing the error is as follows:
var app = new Microsoft.SqlServer.Dts.Runtime.Application();
var pkg = app.LoadPackage(strSSISPath, null);
pkg.ImportConfigurationFile(strSSISConfig);
var result = pkg.Execute();
if (result.Equals(DTSExecResult.Success))
{
string strMsg = strMHType + " extract completed successfully.";
MessageBox.Show(strMsg, strMHType, MessageBoxButtons.OK, MessageBoxIcon.Information);
}
else
{
foreach (var err in pkgMHMDS.Errors)
{
MessageBox.Show(err.Description, strMHType, MessageBoxButtons.OK, MessageBoxIcon.Error);
}
MessageBox.Show(strMHType + #" extract failed!", strMHType, MessageBoxButtons.OK, MessageBoxIcon.Error);
}
pkgMHMDS.Dispose();
The error that we see (the COM class error) is caused because the version of the Microsoft.SqlServer.ManagedDTS dll is not installed on the target machine. Whilst we did install the dll into the GAC we couldn’t work round the error because Integration Services is a server component and is not redistributable to client computers. The error isn’t terribly informative but essentially what it is trying to say is that it is trying to load an assembly who’s address is stored in the registry key which is created when installing the Client Tools SDK.
Related
I try to create a database in the local cosmosDB emulator but this fails to work. It throws an exception with the following message:
Response status code does not indicate success: InternalServerError
(500); Substatus: 0; ActivityId: 36f6a95d-26d7-4ecd-9c81-f6df220f3cdc;
Reason: (Unknown server error occurred when processing this request.
ActivityId: 36f6a95d-26d7-4ecd-9c81-f6df220f3cdc,
Microsoft.Azure.Documents.Common/2.14.0,
Microsoft.Azure.Cosmos.Tracing.TraceData.ClientSideRequestStatisticsTraceDatum,
Windows/10.0.19042 cosmos-netstandard-sdk/3.24.1);
This error happens in my project as well as in an simple, empty console app only containing these lines of code:
using Microsoft.Azure.Cosmos;
namespace CosmosDBTest;
class Program
{
public static async Task Main()
{
using var client = new CosmosClient("<A local connection string>");
var response = await client.CreateDatabaseIfNotExistsAsync("test", 500);
var database = response.Database;
await database.CreateContainerIfNotExistsAsync("container1", "id");
}
}
The version of the emulator I use is 2.14.6. The version of the NuGet package is 3.26.1
What is causing this exception and how do I solve this? I has worked with older versions of the emulator in combination of an older version of the NuGet package. But before I downgrade the emulator and/or package, I want to find out if there is a better work around.
I haven't tried the demo application which is offered by the emulator. Funny enough as it is on a tab with the name ".NET" (and another tab .NET core next to it) the ".NET" example is written in the very old version .net core 2.1 which I don't have installed even.
Try resetting the Emulator, this looks like a malfunction on the Emulator itself. The HTTP 500 is coming from the Emulator, the SDK is just surfacing the response.
Reference: https://learn.microsoft.com/azure/cosmos-db/troubleshoot-local-emulator
If you installed a new version of the emulator and are experiencing errors, ensure you reset your data. You can reset your data by right-clicking the Azure Cosmos DB Emulator icon on the system tray, and then clicking Reset Data…. If that does not fix the errors, you can uninstall the emulator and any older versions of the emulator if found, remove C:\Program files\Azure Cosmos DB Emulator directory and reinstall the emulator.
Alternatively if resetting the data doesn't work, navigate to %LOCALAPPDATA%\CosmosDBEmulator location and delete the folder.
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 write a program that should run on a lot of machines
I did not installed Access in the machines But I have an access database using on them
When I write and delete data from this Access databases its size grow up so every few days I have to compacts them and to shrink the size
This is the code I using
public void Compacting()
{
try
{
Microsoft.Office.Interop.Access.Application application = new Microsoft.Office.Interop.Access.Application();
string dbName = "";
try
{
dbName = ConfigurationManager.ConnectionStrings["LocalPulserDB"].ConnectionString.Split("Data Source=").Last().Split(";").First();
}
catch (Exception ex)
{
string localDbError = "DataBase location is incorrect ";
System.Windows.MessageBox.Show(localDbError);
Environment.Exit(1);
}
CompactAndRepair(dbName, application);
}
catch (Exception ex)
{
try
{
LocalPulserDBManagerInstance.WriteLog(ex.StackTrace, ex.Message);
}
catch (Exception)
{
}
}
}
private void CompactAndRepair(string accessFile, Microsoft.Office.Interop.Access.Application app)
{
string tempFile = Path.Combine(Path.GetDirectoryName(accessFile),
Path.GetRandomFileName() + Path.GetExtension(accessFile));
app.CompactRepair(accessFile, tempFile, true);
app.Visible = false;
FileInfo temp = new FileInfo(tempFile);
temp.CopyTo(accessFile, true);
temp.Delete();
}
But I got the next error :
{"Retrieving the COM class factory for component with CLSID {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE))."}
What can I do?
Interop requires Office to be installed on the machine the code is running on, I suspect you won't be able to utilize that method for performing the compact and repair.
https://social.msdn.microsoft.com/Forums/en-US/973ce94f-5235-4be9-a2b1-51ba7d35e1f3/installing-office-primary-interop-assemblies-without-actually-installing-office?forum=innovateonoffice
You may however be able to utilize this standalone tool, "Jet compact utility":
https://learn.microsoft.com/en-us/office/troubleshoot/access/jet-compact-utility-download
You do not need nor even want to create a whole instance of access to just compact. (or even use + pull data from the tables.
Set a reference to the ACE database engine. That way you can pull + use data, and not have to automatic (create) a rather heavy application object like Access. And if you do create a WHOLE instance of Access, then things like VBA code and startup forms run (not only is a that bad since now you have a hidden UI - but you can't answer prompts, and worse that startup code may will have launched a form which in term will open a table, and then you can't compact until such time all tables are closed.
IN vb.net code, this will compact:
Dim ACEEngine As New Microsoft.Office.Interop.Access.Dao.DBEngine
Dim strDatabase As String = "c:\test\test44.accdb"
' you always compact to a copy - you cannot compact "over" the existing database
Dim strTempDB As String = "c:\test\temp.accdb"
Debug.Print("starting compact")
Try
ACEEngine.CompactDatabase(strDatabase, strTempDB)
Debug.Print("compact done")
Catch ex As Exception
Debug.Print(Err.Description)
End Try
Note that:
You can check the error code as per above, since if ANY other users are in the database, then the compact will NOT occur.
The above output if a someone else has the database open?
starting compact
Exception thrown: 'System.Runtime.InteropServices.COMException' in ACETest.exe
You attempted to open a database that is already opened by user 'Admin' on machine
'ALBERTKALLAL-PC'. Try again when the database is available.
So, catch the error. As above shows, you need a interop reference to
C:\Program Files (x86)\Microsoft Visual Studio 12.0\
Visual Studio Tools for Office\PIA\Office14\
Microsoft.Office.interop.access.dao.dll
Just check that err.Number is 0. If the compact occurred, then you can delete or better yet rename the original database, and then rename the "temp" database back to the original name. (A compact + repair from the Access UI does this behind the scenes and actually never overwrites the original file during the compact process as it might fail or not work). You could attempt to check for existing .ldb file (a lock file) before you attempt the compact, but the compact process checks + requires that you have 100% exclusive use of the file, and if the compact can't get exclusive use of the file, then a error message is spit out as per above.
So, just add the assembly reference to your project. You should also force your .net project to x86, and not leave it to "ANY CPU".
the above will work WITHOUT Access having been installed. However, you will need to have the JET or ACE data engine installed. The JET engine is installed on all copies of windows by default - but will ONLY work with mdb files. If you need to compact and use a accDB file, then you will have to install the ACE database engine - but it is a FAR smaller footprint and install then is a whole copy of Access or the run time (both are about the same size and are quite large. As noted, with above, then you don't require Access to have been installed on the computer.
Edit
You can find + install a version of ACE from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
Note in above, you are given two choices. (x32 or x64 - so you have to install the version you want. This also suggests you need two versions of your .net code OR YOU CAN find a shortcut way to launch "any" cpu to start as x32 or x64 - HOW you start your .net project will determine if it is running as x32 or x64 if you going to choose "any cpu" as opposed to forcing the .net project (and providing two versions of the project as I have done in the sample link below).
I have a working .net (tiny) .exe file from here that lets you run as x32, or x64, and thus you can quick check which version of ACE you have installed.
link:
https://onedrive.live.com/embed?cid=B18A57CB5F6AF0FA&resid=B18A57CB5F6AF0FA%21101313&authkey=AB-I3mHVZhLmd2Q
I am trying to move a deployment to a new Azure VM with SQL Server 2016. I am receiving the following error when trying to run the mvc app locally on the server.
Unable to load DLL 'SqlServerSpatial110.dll': The specified module
could not be found. (Exception from HRESULT: 0x8007007E)
The fix for me was to manually copy sqlserver110.dll to the c:\windows\system32 folder on the new server. I feel this is a step backwards, and I should really be trying to redirect the call to the sqlserver130.dll that installed on the new server by default with SS 2016. I tried updating EF 5 to the latest version, but this did not seem to fix the issue. Any suggestions?
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)