I've created a custom connection manager for SSDT BI (SSIS) which will connect to an Oracle database using Oracle's managed data access library (Oracle.ManagedDataAccess.dll).
On my development machine, this connection manager, and the custom "data source" pipeline component which goes with it, will work fine. When I deploy the package to the server and try to run it, the package will always fail with an "AccessViolationException".
The server is running Windows Server 2012R2 with Sql Server 2014
So far, debugging hasn't give me much info. When I step though my code, my empty, default, constructor gets called but nothing else. As soon as it exits the constructor I get the exception. No other methods within my custom class are ever called.
Here's the information which is dumped to the windows event log.
Application: ISServerExec.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
at Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSPackagePersist100.LoadPackageFromXML(System.Object, Boolean, Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSEvents100)
at Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSPackagePersist100.LoadPackageFromXML(System.Object, Boolean, Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSEvents100)
at Microsoft.SqlServer.Dts.Runtime.Package.LoadFromXML(System.String, Microsoft.SqlServer.Dts.Runtime.IDTSEvents)
at Microsoft.SqlServer.Dts.Runtime.Project.LoadPackage(Microsoft.SqlServer.Dts.Runtime.IProjectStorage, Microsoft.SqlServer.Dts.Runtime.Package, System.String, Microsoft.SqlServer.Dts.Runtime.IDTSEvents)
at Microsoft.SqlServer.Dts.Runtime.PackageItem.Load(Microsoft.SqlServer.Dts.Runtime.IDTSEvents)
at Microsoft.SqlServer.Dts.Runtime.PackageItem.LoadPackage(Microsoft.SqlServer.Dts.Runtime.IDTSEvents)
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ISServerExecutionEvents.LoadPackage(Microsoft.SqlServer.Dts.Runtime.PackageItem)
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ProjectOperator.StartPackage()
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ProjectOperator.PerformOperation()
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ExecuteMain.Main(System.String[])
I've run into a similar issue before. The resolution was the sql server agent not having correct permissions to use the dll file.
Possible Fixes:
Check the location of the dll on the server.
Confirm permissions to use the dll.
Sorry I can't provide more precise fixes, the DBAs at my site ended up fixing it for me and this was the summary they gave me after.
can you sketch for me the outline of the SSIS package?
I have a hunch that this problem can occur when nesting Sequence Container objects in SSIS 2008. When you create a package with SQL Business Intelligence Development Studio 2008, and nest Sequence Containers, and then upgrade the package to SSIS 2012 or greater, and then open the package in SQL Server Data Tools 2012 or greater, the package will not display the same way as it did in 2008. The outer sequence container will not be attached to anything.
Related
I wrote a small app to learn more about SQL and experiment with Entity Framework. On first execution, my app creates the database locally, and after that opens the existing database. So far, so good - it works pretty well on my laptop, which has SQL Server 2017 installed.
I tried copying the assemblies to my desktop machine and that also worked as expected, though SQL Server was not installed.
But when I tried copying the assemblies to another laptop, the app would not run. The exception I saw was:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The Server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 52 - Unable to locate a local Database
Runtime Installation. Verify SQL Server Express is properly installed
and that the Local Database Runtime feature is enabled.)
All machines are Windows 10. (Is it significant that the desktop machine has Visual Studio 2019 installed?)
I can't seem to find a post here which speaks to my problem. (I'm probably not phrasing my query well...)
Anyway, I don't want other users to be required to install SQL Server (Express, or otherwise). What do I need to include in my installation?
Can it be done more-or-less automatically by using ClickOnce deployment (a.k.a. Publishing Wizard)? Or do I need to build an .msi with Wix code?
Is SQLite a better option for this? Users of my app will not be sharing databases; each will have their own.
I have seen mention of SQL Server Compact Edition in this post: ASP.NET MVC - Switching from SQL Server Express to Compact Edition - Connection Issue, but when I tried to run this down, it seemed like this is no longer available from Microsoft. And I believe I'm already using SQL Server Express (looks like this is confirmed by the error message, above)...
At present I have worked around this problem by using ClickOnce deployment. In the near term, I would like to change the installation to include the dependencies (.NET & SQL runtimes) in the setup package, rather than downloading them at install-time.
But I wonder if SQLite would be a better long-term solution... One thing I have appreciated about SQLServer is that I can use SQLServer Management Studio to get at the database apart from the app, so I can validate what the app has done. I also think this is a good thing for users, as they will always have a second option for getting their data, if something goes wrong with the app.
Does SQLite provide any tool similar to SQLServer Management Studio for accessing the database?
SQLite is a better option as it is an embedded database. This means that it is a part of your application and doesn't require additional setup. It works well for storing per-user data that is not shared.
https://www.sqlite.org/whentouse.html
SQLite only requires its assemblies for deployment.
SQLite deployment for .net application
Recently I came across a strange issue where some variables were being assigned incorrectly within a C# task in a DTSX package but where not causing an error in SSIS installed on SQL Server 2012, but did error on SQL Server 2016.
Essentially the bug was as follows:
Variables.ContainerDisable100 = C100;
Variables.ContainerDisable101 = C101;
Variables.ContainerDisable102 = C102;
Variables.ContainerDisable102 = C103;
As you can see Variables.ContainerDisable102 should have been Variables.ContainerDisable103. This should cause an error further does the execution of the dtsx package when it is ran. However this did not cause an issue on our local environments as we were using SQL Server 2012, however on SQL Server 2016 this caused the expected error.
My theory is that someone updated the C# code within this dtsx package using Notepad++ rather than Data Tools. This meant the C# code wasn't recompiled and when SQL Server 2012 ran the compiled code it worked fine.
Which leads me on to my question, does SQL Server 2016 SSIS still look at the compiled code or does it look at the uncompiled C# code?
It's a very strange issue and this is the only hunch I have. When I manually opened the C# task in data tools, made a small change and built and saved it the error then occurred in SQL Server 2012, which makes me believe it didn't build correctly previously or it was updated via the XML.
Update
So I've confirmed that the customer install is running the C# code and not the pre-compiled binary. The setup is as follows:
SQL Server 2016
SQL Server Integration Services 13.0
When I update the dtsx with notepad++ and only update the C# code and run the package using SQL Server Job Agent it fails. This should not be the case as it should be looking at the precompiled binary. I can't see anything regarding this in Microsofts What's New page.
This has been a needle in a haystack kind of issue but I've got to the bottom of it.
There was a bug within the package which I mentioned above, this bug however was not compiled and stored in the dtsx which meant when running locally I did not receive an error.
My local install was using
SQL Server 2012
SQL Server Integration Services 11.0
However when the customer tried to execute these packages they received errors. There setup was as follows:
SQL Server 2016
SQL Server Integration Services 13.0
The packages which they are running was developed in SQL Server Data Tools 2010 with a target version of SQL Server 2012. They were not updated to be ran with SQL Server 2016.
When executing these packages dtexec Utility is smart enough to see the version mismatch and it temporarily upgrades the package in order to run it. When it upgrades the package it re-compiles the C# code which in turn causes the error.
I believe there was an issue during the build of the C# script task or a developer manually updated the C# code via the dtsx XML which meant the pre-compiled C# was never re-compiled which caused this issue to be found.
I hope this helps others avoid this issue in the future.
I have made an application in VS2012 that uses a database to store and retrieve data and I'd like to create a setup file for this application, currently I use InstallShield LE 2012.
I've tried to deploy the application with that, but when I install it in another computer it throws me an exception due to the database.
If you are getting a Null reference exception error this is normally because some place in the code there is a failure to create an object. Then at a later point the use of this object fails with a Null Exception because the object does not exist.
In this case is sounds like there is a failure to create some object that is a dependency for creating the database. I know this does not really give much more insight into why this is happening. But here are some points to look for.
Is the target PC running an SQL server, or does your Install package deploy SQL Express?
Is it a MS SQL DB or Other
Does the user that you are running the install shield under have permissions on the SQL Server to create a database?
I am working on a SSIS Package using SQL Server 2012 and Visual Studio 2010 Shell.
I need to use a web method in a script task I have and I was able to run this script on windows 7 without any problems. This web service requires a certificate which I have installed in my personal computer store.
However when I moved this project into Windows Server 2008 R2, the package breaks for apparently no reason. I have no compilation errors on the Error List and if build the script task it will succeed, however when I finish editing the script a message box will appear with this error message:
"Scripts contained in the package have compilation errors. Do you want to save changes?"
If I remove the web reference from the script task, this message wont appear.
The package won't run because of this. I checked for error details on the Event Viewer, but it only shows "Package Failed" and no further details appear about this issue. Could this be related to a certificate issue? Is there an error log or way to know more details about what is causing the package to fail?
Thank you.
It isn't just the security issue of certificates required by the web service itself that you have to worry about.
The SSRS web server will not allow loading assemblies that are marked as "unsafe"--which is pretty much anything that does I/O. I once added a reference to a .Net Forms assembly to an SSRS report in order to use its rich text functionality. It worked beautifully in Visual Studio, but once deployed to the SSRS web server, it would never run. I am certain it could be made to function, but due to other priorities I actually gave up the job as everything I tried didn't work.
Searching online for adding custom assemblies yields some useful information for getting custom assemblies working. Here are some of the crucial steps:
Sign the assembly with a strong name, required because it is deployed to the GAC.
Use the assembly-level attribute [assembly:AllowPartiallyTrustedCallers] in the assembly so SSRS can use it.
A couple of likely resources are here and here.
I am trying to connect to DB2 from .NET 2.0 application in my development machine running windows 7 64 bit.
I am getting this error in open method. Could not find a solution.
ExceptionType: InvalidOperationException
ExceptionMessage: SQL1159 Initialization error with DB2 .NET Data Provider, reason code 2, tokens D:.......................\bin\db2app.dll,
StackTrace: at IBM.Data.DB2.DB2ConnPool.Open(DB2Connection connection, String& szConnectionString, DB2ConnSettings& ppSettings, Object& ppConn)
at IBM.Data.DB2.DB2Connection.Open()
Learnt this from a colleauge of mine. Issue was because db2app.dll was missing in bin directory of application folder.
Copied db2app.dll and db2app64.dll from C:\Program Files\IBM\SQLLIB\BIN to bib folder of application and it worked fine.
See the "user response" at the bottom of the IBM doc for SQL1159N, which also lists the various reasons you might receive this error code:
There was a problem with your DB2 installation. If this is the first time DB2 was installed on this computer, review the install logs for any possible errors and run a repair of DB2 from the Add/Remove Programs control panel applet. The default location of the installation logs is the My Documents/DB2LOG folder of the user that performed the installation. If this does not resolve the issue please contact IBM Support and provide the reason code associated with this message along with any installation logs.
I had a 32 bit DB2 Client and I was accessing it from a Web Application hosted on IIS, using Application pool (with 'Enable 32-bit Application' set to false). In this case a
64 -bit client (db2app64.dll)
is expected while db2app.dll will throw above error.
Just FYI..
It is hard to debug this error in Visual studio as by default IIS express uses 32-bit application pool. To change it to 64-bit, one has to make changes in registry (set Use64BitIISExpress to 1) There is no inetmgr for IIS Express.
After speaking to IBM, they recommend strongly against putting IBM dlls inside the bin folder. We let IBM remotely configure our server and now all works well and we must not put the ibm*.dll into our bin folders or it will not work.