I'm running a SQL 2012 Standard Edition and Visual Studio 2010 within a Virtual Server and I'm running a Package via SQL Server Job and I get the following error:
06/17/2014 16:35:57,A_E,Error,,X,A_E,,,The job failed. The Job was invoked by Schedule 17 (A_E). The last step to run was step 1 (A_E).,00:00:19,0,0,,,,0
06/17/2014 16:35:57,A_E,Error,1,X,A_E,A_E,,Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 11.0.2100.60 for 64-bit Copyright (C) Microsoft Corporation. All rights reserved. Started: 16:35:57 Error: 2014-06-17 16:36:15.87 Code: 0xC00470FE Source: Data Flow Task 1 SSIS.Pipeline Description: The Fuzzy Lookup cannot run on the installed edition of Integration Services. It requires Enterprise Edition (64-bit) or higher. End Error Error: 2014-06-17 16:36:15.87 Code: 0xC00470FE Source: Data Flow Task 1 SSIS.Pipeline Description: The Fuzzy Lookup 1 cannot run on the installed edition of Integration Services. It requires Enterprise Edition (64-bit) or higher. End Error Error: 2014-06-17 16:36:15.87 Code: 0xC00470FE Source: Data Flow Task 1 SSIS.Pipeline Description: The Fuzzy Lookup 2 cannot run on the installed edition of Integration Services. It requires Enterprise Edition (64-bit) or higher. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 16:35:57 Finished: 16:36:15 Elapsed: 18.236 seconds. The package execution failed. The step failed.,00:00:19,0,0,,,,0
The Package runs fine in BIDS but when I remove the Fuzzy lookup from the package the package works via SQL Server Job I don't get the error above.
Thanks
Below transformations are supported only by Enterprise edition.
Persistent (high performance) lookups
Data mining query transformation
Fuzzy grouping and lookup transformations
Term extractions and lookup transformations
You can build and test an SSIS package using Enterprise-Edition-only components, but you cannot execute this package outside the SQL Server Data Tools environment.
Check this official SQL server edition comparison article. Have a look of this thread as well.
Related
I started a new job with a brand new laptop and vanilla environment.
I have installed Visual Studio and I'm trying to convert a XLS file to TXT. This is my Control Flow:
And this is my Data Flow:
When I run the package I incur in the notorious error:
SSIS package "C:\Users\fmv\source\repos\XtoT\XtoT\Package.dtsx" starting.
Information: 0x4004300A at Data Flow Task, SSIS.Pipeline: Validation phase is beginning.
Error: 0xC0209303 at Package, Connection manager "Excel Connection Manager 2": The requested OLE DB provider Microsoft.ACE.OLEDB.12.0 is not registered. If the 64-bit driver is not installed, run the package in 32-bit mode. Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
Error: 0xC001002B at Package, Connection manager "Excel Connection Manager 2": The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. For more information, see http://go.microsoft.com/fwlink/?LinkId=219816
Error: 0xC020801C at Data Flow Task, Excel Source [2]: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Excel Connection Manager 2" failed with error code 0xC0209303. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
Error: 0xC0047017 at Data Flow Task, SSIS.Pipeline: Excel Source failed validation and returned error code 0xC020801C.
Error: 0xC004700C at Data Flow Task, SSIS.Pipeline: One or more component failed validation.
Error: 0xC0024107 at Data Flow Task: There were errors during task validation.
SSIS package "C:\Users\fmv\source\repos\XtoT\XtoT\Package.dtsx" finished: Failure.
The program '[18396] DtsDebugHost.exe: DTS' has exited with code 0 (0x0).
I tried to switch the connector to Microsoft.ACE.OLEDB.16.0 but the error is the same.
So I read some guide and they mostly suggest to download Microsoft Access Database Engine. So I download the Microsoft Access Database Engine 2016 Redistributable and when I run the 32-bit it says:
You cannnot install the 32-bit version of Microsoft Access Database Engine 2016 because you currently have 64-bit Office products installed. If you want to install 32-bit Microsoft Access Database Engine 2016, you will first need to remove the 64-bit installation of Office products. After uninstalling the following product(s), rerun setup in order to install 32-bit version of Microsoft Access Database Engine 2016: Office 16 Click-to-Run Extensibility Component 64-bit Registration
So I tried with the 64-bit instead and the computer says:
You cannnot install the 64-bit version of Microsoft Access Database Engine 2016 because you currently have 32-bit Office products installed. If you want to install 64-bit Microsoft Access Database Engine 2016, you will first need to remove the 32-bit installation of Office products. After uninstalling the following product(s), rerun setup in order to install 64-bit version of Microsoft Access Database Engine 2016: Microsoft Access database engine 2010 (English), Office 16 Click-to-Run Extensibility Component
...so, which is which? I currently have Microsoft® Outlook ® for Microsoft 365 MSO (16.01380120442) 32-bit.
So I found anotherguide here on StackOverflow that said that the right version I need is Microsoft Access Database Engine 2010 Redistributable. And it was true, at least I was able to install the 32-bit.
But apart from that I'm still experiencing the problem even if I don't have red dots on the control Flow or on the Data Flow.
Any idea about how to try next?
As per the Microsoft documentation on DTEXEC for executing SSIS packages:
When you use the version of the dtexec utility that comes with SQL
Server 2012 Integration Services (SSIS) to run a SQL Server 2005
Integration Services (SSIS) or a SQL Server 2008 Integration Services
(SSIS) package, Integration Services temporarily upgrades the package
to SQL Server 2012 Integration Services (SSIS).
Is there a feature to disable this aspect of DTEXEC utility when running SSIS packages?
My reason for this question is that I have a script task to rename some files in an SSIS package. This works just fine on my local machine and a coworkers local machine, but after deploying this SSIS package to our windows 2012 server with SQL Server 2012 installed I get an error message. I'm really confused, because I wrote this package in SQL Server 2012 Data Tools so this task shouldn't need to be upgraded/migrated at all, which is what the error is complaining about...
Warning: 2016-04-06 11:29:58.14
Code: 0x00000000
Source: DataMergeScriptTask
Description: Found SQL Server Integration Services 2012 Script Task "my_Script_task" that requires migration!
End Warning
Error: 2016-04-06 11:30:03.02
Code: 0x00000001
Source: DataMergeScriptTask
Description: Exception has been thrown by the target of an invocation.
End Error
Unfortunately we haven't found a solution for the Script Task not converting into 2012, as these packages are all written in Data Tools 2012 and opening/resaving the task doesn't seem to actually upgrade the script task in a way that solves it on the server.
My solution has been to take the C# script and turn it into a standalone .exe which has some command line arguments to pass our different parameters with defaults in place to match our current environment. Then I set this up to be executed by a Batch script called by a windows task scheduler job.
I'm hoping to find a real fix for this so that script tasks in larger packages will still be peachy, but that may take more time or a reinstall of data tools... Having multiple versions of SQL Server data tools/BIDS on my workstation could be a cause of this grief. More testing to come!
Just update the TargetServerVersion in your package to match the server version that you plan to deploy to.
Make sure you have a copy of your project in case it doesn't go smoothly. Then right click on the project name, choose properties, then drill into Configuration Properties -> General and update the TargetServerVersion.
Then rebuild and deploy. When the project builds, it should now be in the format that your server expects so it won't try to rebuild the script code on the server where references might not be the same.
The logs corresponding to the failed job are as follows:
04/11/2014 06:40:00,LPR_New,Error,0,USPHND0088,LPR_New,(Job
outcome),,The job failed. The Job was invoked by Schedule 14
(LPR_New_Job). The last step to run was step 1 (Upload
Material).,00:00:00,0,0,,,,0
04/11/2014 06:40:00,LPR_New,Error,1,USPHND0088,LPR_New,Upload
Material,,Executed as user: nestle\ussqldbserver. ...00.5324.00 for
32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 6:40:00 AM Error: 2014-04-11 06:40:00.39 Code:
0xC001700A Source: Description: The version number in the
package is not valid. The version number cannot be greater than
current version number. End Error Error: 2014-04-11 06:40:00.39
Code: 0xC0016020 Source: Description: Package migration from
version 3 to version 2 failed with error 0xC001700A "The version
number in the package is not valid. The version number cannot be
greater than current version number.". End Error Error: 2014-04-11
06:40:00.39 Code: 0xC0010018 Source: Description: Error
loading value "3" from node
"DTS:Property". End Error Could not load package
"\usphnd0088\dataxfer\LPR\LPR New\UploadMaterial.dtsx" becau...
Process Exit Code 5. The step failed.,00:00:00,0,0,,,,0
Have you checked what version of BIDS the project file was built in? This happens when the sql server agent's version is different from the one used to build the project that the SSIS package lives in.
There is a suggestion to rebuild the project in the correct version of BIDS that matches the server agent used to run the job. One other option is to set the location/path of the DTEXEC file you want to use (depending on which version you are using).
References: MSDN / Package migration from version 3 to version 2 failed with error 0xC001700A. The version number in the package is not valid. The version number cannot be greater than current version number.
Per this blog: http://blogs.msdn.com/b/jason_howell/archive/2014/09/30/ssis-error-when-deploying-from-vs-2013-to-ssisdb-in-sql-2012.aspx
The underlying cause is that currently (Sept 2014 timeframe) SSDT BI 2014 for Visual Studio 2013 does not support SSIS packages for SQL Server 2012.
It is a common feature request, and the product group is well aware of the demand.
http://connect.microsoft.com/SQLServer/feedbackdetail/view/944882/ssdt-bi-2014-backward-compatibility-for-ssis-2012
At present SSDT for VS 2013 only works with SQL Server 2014. You have to use SSDT-BI for Visual Studio 2012 with SQL Server 2012 SSISDB.
To provide a newer answer, using SQL Server Data Tools 2015, you can set the Deployment Target Version for your integration project to 2012, 2014 or 2016 (It defaults to 2016 and will result in version number errors on 2012/2014 DBs until you set it correctly). I successfully deploy SQL 2012 integrations now from SSDT 2015 after setting to "SQL Server 2012".
I had the same problem. here is how I easily solved it without messing with Visual studio. Of course the management studio on my desk is the latest version so when I exported/Imported using my management studio i had the error.
Actually Remote desktop into the legacy server and export the SSIS Project from that version of management studio.
While on the legacy server connect to the destination server of the same version and import.
I also found some fancy stuff where I had some aliases in the configuration manager aliasing some decommissioned servers.
One of the aliases was using Named pipes, that protocol was turned off on the destination so I turned that protocol on.
Did step 3,4 for both the 32 bit and 64 bit, and of course RDP'd into the destination server to make those changes.
I'm upgrading our ETL solution and databases to SQL server 2012. I have tested this upgrade but we have a debate about running an SSIS 2008 package with the Job on the SQL 2012 instance. I understand that the 2008 R2 instance job runs:
Message Microsoft (R) SQL Server Execute Package Utility Version
10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 2:10:11 AM DTExec: The package execution returned
DTSER_SUCCESS (0)...
and the 2012 instance job does an in-place upgrade of the packages and runs:
Message Executed as user: xxxx. Microsoft (R) SQL Server Execute
Package Utility Version 11.0.2100.60 for 64-bit Copyright (C)
Microsoft Corporation. All rights reserved. Started: 8:29:18 AM
DTExec: The package execution returned DTSER_SUCCESS (0). Started:
8:29:18 AM Finished: 8:59:46 AM Elapsed: 1816.76 seconds. The
package executed successfully. The step succeeded.
My question is this: Are there any reports of failure for such scenario and is it safe to assume there is a backwards compatibility?
From this page, DTExec 2012 converts earlier version packages in-memory to 2012 format. It is conceivable that the conversion could fail, however, it should be possible to test the packages, and if they run successfully once (i.e. convert successfully) then they should do so every time. Their behavior should be similar to a high degree, but I would not expect complete equivalence in all circumstances.
The most likely scenario for conversion failure is if the package includes third-party components that are not available for SSIS 2012.
I would not assume that a package can be run by a later version of DTExec without testing, but if it runs successfully once, there is a high probability that it will run successfully every time.
Not 100% backwards-compatible. E.g. a SSIS 2008-edited package that extracts data from flat file and doesn't specify row & column delimiters will work in 2008, but if you run that package on a SSIS 2012 server, the empty row & column delimiters will cause the extract to go nuts, it will import zillions of columns/rows (because it never finds a column/row ending). Big issue for me, currently.
There is one case I've found an issue with this that I wanted to share:
If you process the SSAS Cubes in SSIS 2008 packages, In rare cases the SSAS database connection provider won't work with the back dated version. See this link
This question already has an answer here:
Executing SSIS 2012 package that has script components from external application
(1 answer)
Closed 8 years ago.
My package runs correctly from BIDS but when I schedule it to run from SQL Agent, it fails with the following error message.
Message
Executed as user: STRW067029\SYSTEM. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 11:00:36 AM Error: 2013-07-31 11:00:45.39 Code: 0xC000F427 Source: Envoy Data Flow Task SSIS.Pipeline Description: To run a SSIS package outside of Business Intelligence Development Studio you must install Standard Edition of Integration Services or higher. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 11:00:36 AM Finished: 11:00:45 AM Elapsed: 9.282 seconds. The package execution failed. The step failed.
I am using same machine to do both tasks and Sql server instance is also local to the machine. I see the package starting and executing couple of "Execute SQL Task" correctly. Then when it comes to and "Excel Source" in dataflow, getting this error.
Clicking into Services (Start -> Run type Services.msc) and revealed that "SQL Server Integration Services 10.0" was not present. This is the SQL Server Integration Services Service which provides some validation that this is Server level installation vs a ssdt/bids developer level installation.
Find your SQL Server installation and set about performing a new installation and in the feature install, only install the Integration Services Service.