SSIS SP Connection using OData connector.
I was able to connect to Sharepoint site fine and was able to see the data thru preview and all.. but when i execute the task i get below error.
[OData Source [2]] Error: The OData Source was unable to process the data. Object reference not set to an instance of an object.
Note: Visual Studio 2012 with BI template not sure how different is that from SSDT 2012. When i go try to open SSDT 2012, i get VS 2010 shell, that's why i use VS 2012 with Business Intelligence template thinking that maybe same as SSDT 2012. If this has to do something with error message i get above.
Task:
OData Source with SP connection information
OLE DB Destination.
Let me know your thoughts!!
I would try setting the Project Properties / Debugging / Run64BitRuntime to False.
This will run your debug executions (e.g. Execute Task, Execute Package using Visual Studio) using the 32-bit version of the OData connector. Visual Studio (which you have used to design the task and preview the data) is a 32-bit app, so it will be using the 32-bit versions of the OData connector.
The same challenge applies to almost every connector or driver that has to be separately installed for SSIS. Typically they come in 32-bit and 64-bit flavors, with independent setup, configuration and sometimes bugs.
While I recognize that 64-bit components will generally deliver higher throughput, I have resigned to always install and use the 32-bit connectors and drivers. I find this minimizes wasted time and frustration trying to debug and resolve these issues on multiple developer machines and servers.
Related
I have a working SSIS package. It works from vs, meaning it builds and executes as expected producing results in the CRM.
After I get the generated .ispac file and deploy it in MSSQL server, I fail on executing.
I get an error that looks like this:
Test Package:Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException: The version of Create Records is not compatible with this version of the DataFlow. [[The version or pipeline version or both for the specified component is higher than the current version. This package was probably created on a new version of DTS or the component than is installed on the current PC.]]
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade(IDTSManagedComponentWrapper100 wrapper, Int32 lPipelineVersion).
The aforementioned 'Create Record' is the 'Dynamics CRM Destination' component.
There are many who have such issue, I searched the web, but what all suggest is that we change the target version of the MSSQL server from VS, but I tried that and it doesn't work.
Additional information:
System: Windows 10 pro
VS: 2015
MSSQL: 13.0.6300.2(so it's sql server 2016)
Kingsway version: v21.2(21.2.0.31501)
The 'TargetServerVersion' is set to: 'SQL Server 2016'
What have I tried ?
I have tried to deploy straight from VS, but no luck there.
I ran the same(separately built) SSIS on my local machine where I have vs2019 and sql server 2019, it works fine in here.
I tried to build the project in vs2019 on the main machine and I'm still getting the same error.
So, do you have any idea what's happening, can you give me some advice ?
Thank you for the question about our integration toolkit. To use any of our toolkits for deployment and scheduled execution, the same version should be installed in possibly three places:
On your development machine (this is generally covered by our free Developer license)
On your SSIS Integration server
On the machine which is used to deploy your SSIS packages to your Integration server (if different from your development machine)
Based on the error message, it is either that you didn't install our Dynamics 365 toolkit or otherwise the installed version on the server is lower than what you have installed on your development workstation.
I got VS 2017 15.8.1 version installed and a legacy SSIS package created and run in VS 2012 version 11.0.61219.00 Update 5. So basically two VS instances on one machine. I also installed SSDT 15.4.0 version for VS 2017. My app saves .csv file on the server, makes a call to SQL Server 2016 which invokes SSIS packages and passes the address of .csv file to it. SSIS processes the file and saves data to the database. All this is working correctly, however, instead of displaying the uploaded file on page as a link the UI throws the following error.
"Error: 2019-05-09 12:06:03.61, Code: 0xC000F427, Source:
SCR_Chk_UploadTypes, Description: To run a SSIS package outside of SQL
Server Data Tools you must install SCR_Chk_UploadTypes of Integration
Services or higher.,End Error,DTExec: The package execution returned
DTSER_FAILURE (1)."
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have some relation to SSDT and VS compatibility.
Thanks!
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have
some relation to SSDT and VS compatibility.
I imagine that is either the name of a connection manager or a Data Source in the data flow(s). Can you post a screenshot?
With respect to the error itself, please note that Microsoft requires a package to target a specific version of SQL Server.
The package that runs in VS2012 can only target SQL Server 2012.
Starting with VS2015, Microsoft introduced the concept of Server targeting. By default, when creating a package in VS2017 the targeted SQL Server will be SQL Server 2017. Have you confirmed that the SQL Server version that the package is targeting is SQL Server 2016?
For more information on targeting
Our organization has a Windows server running SQL Server Reporting Services (SSRS). We use SSRS to build reports that access an Oracle database. We were able to get SSRS to connect to our Oracle database by installing Oracle Data Access Components (ODAC) for Windows on our server. We installed the Xcopy versions - both 32-bit and 64-bit (don't know if we needed to do both; SSRS used to only accept 32-bit drivers). We were able to successfully set up a data source in SSRS that connected to the Oracle database.
However, we write our reports on development machines using SQL Server Report Builder 3.0. When building a report that uses a shared data source on the server - the one that accesses our Oracle database, we get the error
The selected data extension ORACLE is not installed or cannot be loaded...
What do we need to do to be able to write reports from our development machines that use a shared data source to our Oracle database?
You need to install ODAC on your development machines as well. Even though you are configuring your report to use a shared data source on the server, Report Builder 3.0 will use connection drivers on the local machine to build and preview report data.
Report Builder 3.0 still seems to be a 32-bit application (as of 6/3/2016), so you only need to install 32-bit ODAC package.
I have been searching for a while on this and have no real direction on what the problem may even be. I haven't done SSIS for about 5 years and even 5 years ago I only did one or two.
I have Visual Studio 2012 on my machine. I installed SSDT so that I could write an SSIS package. I have the package written and working locally but when I try to set up a job in the SQL Agent on the server I get this error after selecting the package:
I have looked into this error and none of the resolutions I have found are working. My project is already set to not use 64 bit mode. I'm kind of thinking this might have to do with the fact that the version of SQL Server on that machine is just 2008 and that maybe that means it has an incompatible SSIS runtime. I don't know if there is an additional runtime I need to install to get this to work and I don't know if it's backward compatible with the old runtime they are using if that's even the problem.
I can't find any information online about setting up the environment for an SSDT SSIS package..
Please help.
Thanks
You have a package built against the SQL Server 2012 Integration Services object model. You are attempting to execute it on a 2008 instance. Backwards compatibility is not an option.
You need to either update the 2008 instance to 2012 (there is a licensing change to be aware of) or recreate your package using the 2008 model.
There are 2 steps you have to do:
1) Build you package using correct version - Update 2208 Instance to 2012
2) If you have multiple versions install and you try to deploy using .ispac file, it will most likely pick the latest version. To resolve the issue, you have to pick the correct version of Installer by going to where it is installed. In my case it is (C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn)
Well, this is a bit awkward. I currently have a set of reports on a 32-bit sql server 2005 instance that references an access database on a network location. I'm currently trying to migrate these over to my new reporting services instance (sql server 2008 64-bit), and i've ran into an issue.
Well, i did a google search on the error and got a bunch of stuff saying to compile to use x86 and use 32-bit, etc., but none of it even touch on if i was getting this in rpeorting services.
My question is, is there a way to "fix" this, or some sort of work-around? Perhaps there's another provide i can use to get to the access database?
Any ideas would be much appreciated.
Ran into the exact same problem today, as you alluded to there is no 64-bit Microsoft.Jet.OLEDB.4.0 provider available. This impacts reports that attempt to use Excel and Access datasources on a 64-bit Reporting Services instance. Here is the KB article confirming that no 64-bit Jet driver is available:
http://support.microsoft.com/kb/957570
The solution I found is from this forum post on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9e999fb4-5a39-41c4-8fd7-46193a223673/
It involves creating an SSIS package that reads the Excel or Access data source, running the SSIS package in 32-bit mode, and using the SSIS package as the report datasource. Not ideal, but it works.
I'm afraid this is the nasty workaround to which we're limited.
I ran across this, which worked in a specific case:
http://danielcai.blogspot.com/2011/02/solution-run-jet-database-engine-on-64.html
From that post:
Microsoft has released a 64-bit compatible Jet database engine last year. The following is the procedure that you may use to fix this issue:
Download Microsoft Access Database Engine 2010 Redistributable (of
course you'll need to choose the right bit for your server), and
install it on your server
Change your connection string in your code or configuration file from
Provider=Microsoft.Jet.OLEDB.4.0;
to
Provider=Microsoft.ACE.OLEDB.12.0;