I know this has been asked many times before but I haven't found a solution to my specific problem.
My setup is a newly installed Windows 10 Enterprise fully updated with SQL Server 2017 incl Integration Service and Analysis Service. I've installed latest SSDT as well. I've also installed client tools SDK from the SQL Server 2017 installation.
Visual Studio 2017 is installed as well.
My ASP.NET application 'should be' running SSIS packages, but it fails when loading the package using LoadPackage(packageName, null).
The error is "an integration services class cannot be found etc etc.....".
Just to repeat - Integration Service 2017 and Client Tools SDK are installed.
My application has been working on previous SQL Server versions - the most recent version is with SQL Server 2014, but I've upgraded my application from SQL Server 2008 to 2008R2 to 2012 to 2014 and I've never met problems before.
What is different from other posts I can find is that I do not deploy the SSIS package to a separate web server (well, I do and that doesn't work either but a first step is to solve it on my dev machine).
I have created an empty SSIS package in VS2017 to ensure it is not the content of the package that causes the error.
The SSIS package is developed on the same machine, and I can run the package with both 32 and 64 bit versions of DTExec.exe successfully.
I have updated any references in my ASP.NET application to ManagedDTS.dll version 14.0.
I've updated my ASP.NET application to .NET 4.7 as part of this update to SQL Server 2017.
As I can easily search and find many posts about similar problems with lots of solution suggestions, I hope someone will reply to this with solution suggestions rather than links to 'copies' of my question, as chances are I've already read those and tried all suggested solutions.
Thanks in advance...
UPDATE:
First of all, creating a new project and loading a package works - so I figured that I might be facing a problem with the code after updating from .NET 3.5 to 4.7.
I started commenting code and found that if I don't do impersonation before calling LoadPackage, it actually works.
Based on some other issues I've had recently with the July updates from Microsoft, I have removed one of the updates and I now get a different error - with the impersonation code enabled.
The current error is one I've seen many other people have so I'll dig into that - it is: "The package failed to load due to error 0x80131534 \"(null)\". This occurs when CPackage::LoadFromXML fails.\r\n".
I don't really understand if this should be caused by a mismatch between versions, but I'll update as I find out more.
If anyone has good suggestions, I'd be happy to hear them :)
As a quick WORKAROUND, you can set sql job calling the ssis package and run the job using the sp_start_job stored procedure from the asp.net app.
If the running job needs to be monitored, status can be checked using:
select * FROM msdb.dbo.sysjobactivity
Related
I'm attempting to set myself up with Azure Data Studio on my new M1 Mac Mini, but the SQL Server database project I'm working on refuses to build. This is the (completely useless) error I'm getting:
stdout: /Users/dumasded/.azuredatastudio/extensions/microsoft.sql-database-projects-0.13.0/BuildDirectory/Microsoft.Data.Tools.Schema.SqlTasks.targets(586,5): error MSB4181: The "SqlBuildTask" task returned false but did not log an error. [/Users/dumasded/Projects/db-project/DBProject.sqlproj]
stdout: 0 Warning(s)
stdout: 1 Error(s)
I can neither find nor remember where I got this idea but I somehow got it into my head that this has something to do with the version of the SDK I'm using - I'm currently using 6.0.100, which as far as I can tell is the only one that's arm64 compatible. Every attempt I've made to download, install and run an earlier version of the SDK on this machine has failed. If that is in fact the problem, I can't even get far enough to find out.
Just to be sure it wasn't something to do with the existing project I was trying to set up, I created a brand new one from scratch and attempted to build that. It failed with the same error. It definitely appears to be a system issue and not a project-specific one.
Is there any hope for me? Am I doomed to return to working on my crummy Lenovo Thinkpad? My breath is bated. Thanks in advance.
EDIT
I've just come across the ingenious MSBuild.Sdk.SqlProj as a potential solution to my issue, however my attempts to use it are still running up against SDK version issues:
error : The current SDK bundles target framework 'netcoreapp6.0' which is not supported by MSBuild.Sdk.SqlProj. Either install a .NET Core SDK that supports 2.1, 3.1 or 5.0, or file an issue at https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/ to add support.
This would seem to confirm my initial suspicion that this is an issue of SDK versions.
EDIT 2
Neglected to mention that I'm using Azure Data Studio with the SQL Database Projects extension, which purports to handle the DACPAC creation seamlessly and across platforms. Though that hasn't been my experience thus far.
I'll be dunked. I knew there had to be a deceptively simple answer to this.
It turns out that my attempts to download, install and run an earlier version of the SDK on my machine weren't failing - they were just going into a different directory. Apparently, installing x64 SDKs on an arm64 machine results in the SDKs being created in a dedicated 'x64' subdirectory of the primary dotnet installation. This is painfully obvious to me now - the reason dotnet --list-sdks showed no trace of the earlier SDKs was that they were being installed for a completely isolated instance of dotnet. All I had to do was point the SQL Database Projects extension to that instance of dotnet and it started working:
I hope my publicly blundering my way through the maze of dotnet SDK architectures manages to help someone else. For my part I'm just so relieved I've finally gotten it to work.
Recently I tried to deploy SSIS packages on our production environment and after struggling with some errors I checked contents of packages by importing them from server(not from deployment file) into SSDT. What I found was really interesting - C# code from Script Task(we got only one script task) was gone, there was only template code even with comments that you see when you add Script Task to your package, it looked like it wasn't ever edited by anyone.
I asked my colleague if he could deploy same project on same server instead of me, and it worked, code was on it's place and everything went smooth from there.
What may have caused this behavior? We both are server admins, we both have sysadmin permissions on SQL Server and we don't know about any permissions that he has and I don't.
EDIT: We were both deploying same .ispac project deployment file, none of us edited it after it was "production ready". We also deploy it in the same way - double click on .ispac file, and using Integration Services Deployment Wizard.
Packages are prepared on different server.
I have experienced a very similar problem. A previous post existed which may have been subsequently removed, but I can attest that the process script task in the SSIS packages are being replaced with an empty or default Task. I suspect an incompatibility in versions or a dll found in the SQL Server\120\DTS\Binn directories.
We currently developed using Visual Studio 2013 Professional with SSDT integrated into it (did not use the shell or standalone version). Development took place on a Windows 7 Enterprise 64-bit machine with SP1. All testing was fine locally using SSDT. When deployed to the server, testing worked as intended. The server is where I believe the problem is originating. We deployed to a SQL Server Enterprise Edition running on Windows Server 2012 R2. Microsoft SQL Server 2014 (SP1-GDR) (KB3194720) - 12.0.4232.0 (X64). The ispac was generated from an export in SSMS in the SQL Server Integration Services Catalog. The ispac was then deployed to another site.
Turns out the site had deployed this to a SQL Server Developer 64 Bit instance. Theoretically, this should work, but when importing the deployed project back into a Visual Studio SSDT standalone instance (not embedded in Visual Studio Professional) at this site, all the Process Script Tasks were replaced with the default instance of a Process Task.
When reproducing the scenario in-house, on a SQL Server 2014 Developer 64 Bit as the deployment site, and then importing it back into a new Visual Studio SSDT project, the Process Scripts are indeed replaced. When creating a new Visual Studio SSDT project and importing them from the Enterprise Edition, the Process Scripts are all there.
For us, it seems to be a strong correlation between the SQL Server versions, or the fact of them being different.
I'm currently trying to debug a weird issue I'm having with some RESTful API calls. I built an Angular 2 scaffold and used the publish feature to create a standalone build which users can run by opening a command prompt and typing in "project --debug" -> this will start the scaffold service and users can submit API calls to retrieve data from files. This works perfectly fine on my machine and I can make the API calls just fine, but I have another computer where the results are different. The other computer always fails and lands in an Exception block when accessing a specific type of file.
I'm wondering if this may have to do with some kind of version mismatch/difference on the .NET Frameworks and/or Microsoft Visual C++ redistributables. The published build (original computer) was built using .NET 4.5.1 while the other computer only has 4.6.1 installed.
Has anyone encountered a similar situation where the exact same build yields different results? I'm currently uninstalling versions of .NET and redistributables to test this hunch out but I'm curious if some of you may have had a similar experience.
Seems like my issue is related to the Microsoft Visual C++ 2015 Redistributables - I removed the 2015 redistributables from the original machine (because it turns on the other machine did not have them), and I received the same results. Going deeper, I'm guessing this is because one of the DLLs was built using the 2015 redistributables.
I have a WPF C# app (.Net Framework 4.5) which I regularly updated and published to an FTP server using ClickOnce (every few months). Now, when I want to publish it to the FTP server, it fails with the following error message: The components for communicating with FTP servers are not installed.
Searching the web and StackOverflow, I read that in some cases Xamarin prevents publishing it, so I uninstalled Xamarin (as advised), but the problem persists. I also tried to publish locally and then manually copy the files to the FTP server, but then Windows Defender blocks the installation for the user. I also updated Visual Studio Enterprise to the latest version (Update 2).
It seems this issue has been there for quite a long time (one, two, three). Does anyone have an idea how to solve the issue, or what else I could try?
kurtdv on MSDN suggested to install the 32-bit version of Visual C++ Redistributable Packages for Visual Studio 2013 from https://www.microsoft.com/en-us/download/details.aspx?id=40784, which solved my problem.
I have a asp.net mvc application which is using oracle 11g database. In development machine every thing worked fine, but while deploying it in production server asp.net application is not able to connect to the database server. It is always throwing an empty exception.
I wrote also a simple console application to test the db connectivity. It is also not working. Then I realized it is because that the machine doesn't have a oracle client installed. so I installed Oracle instant client for 11g database 32 bit version. After this the console application started working but the web application still could not connect.
I google lot and finally decided to analyse using process monitor. In process monitor I found that the web application (iis) is looking for an oraclient12.dll.
This oraclient12.dll is part of oracle client for 12c database. I can't understand why it is looking for this dll.
After installing oracle database client for 12g, the above issue with oraclient12.dll got fixed. but iis is now not able to locate oraclsce12.dll.
I searched the whole file-system for this file but could not find.
does anyone know what should i install to get oraclsce12.dll.
Thanks,
Sujith
I was facing similar issue, then came to know that for the dll to be installed you should now also install the option «Oracle Advanced Security»,, by choosing custom installation when installing the oracle 12 client. I did the same and my issue got resolved. You can try this and see if your issue gets resolved.
thanks Sudharsan
This is documented as Oracle bug 17379890.
Oracle provides two workarounds:
Workarounds include:
To avoid the issue in the first place, explicitly select "Oracle NET" component during install
After the fact, you can
do another custom install into the same home, and select "Oracle NET"
copying ORACLSCE12.DLL from an existing install into OH\bin also resolves the issue.
However, making a single copy of file ORACLSCE12.DLL is not sufficient because there are more files which are missing. The workaround works only for certain applications. For example for tnsping.exe you still get an error due to missing files.
You have to take the first solution, i.e. explicitly select "Oracle NET" component during install