July 11, 2014 at 5:24 am
Im running BIDS 2013 on a 64 bit server, connecting to 64 bit SQL 2014.
When i create a new SSIS project, I can create connections without issue.
I have upgraded an old project and get the following error when running:
ng task validation.
Error at LoadProduct [Connection manager "DWH1"]: The requested OLE DB provider SQLNCLI10.1 is not registered. If the 32-bit driver is not installed, run the package in 64-bit mode. Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
If i then go to the connection i get a message box stating:
The specified provider is not supported. Please choose different provider in connection manager.
I have tried:
-updating the connection manager, selecting OLE DB for SQL. The test succeeds but once i run the package i get the first error again, and then have to re-edit the connection manager and thus go round in a circle.
I have other projects that are working fine so im not sure whats up with this one. Any help would be appreciated.
July 11, 2014 at 5:28 am
Any package configurations or something like that?
I think you need to use a more recent version number for the SQL native client.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
July 11, 2014 at 5:35 am
Koen Verbeeck (7/11/2014)
...I think you need to use a more recent version number for the SQL native client.
+1
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
July 11, 2014 at 7:00 am
You got it in one guys! thanks a mil!
January 4, 2016 at 12:57 pm
Post is a little old, but I ran into this issue and the solutions offered didn't help me. So in the event someone else runs across this and the solution above doesn't help try editing the command line in the SQL job itself. This seemed to override the connection string I was using in the package. Not at all intuitive as to why this might happen and why this is the solution.
January 4, 2016 at 1:07 pm
RonKyle (1/4/2016)
Post is a little old, but I ran into this issue and the solutions offered didn't help me. So in the event someone else runs across this and the solution above doesn't help try editing the command line in the SQL job itself. This seemed to override the connection string I was using in the package. Not at all intuitive as to why this might happen and why this is the solution.
Whatever you configure against the SQL Agent job does override what's in the package ... it's a feature.
Are you sure that the connection string you were 'using in the package' was not being overridden by a config item (eg, an Environment Variable)?
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
January 4, 2016 at 1:14 pm
Are you sure that the connection string you were 'using in the package' was not being overridden by a config item (eg, an Environment Variable)?
Yes, I'm sure. I assumed based on some answers that maybe there was an expression or something else set in the package. The package itself is a pretty simple one so there wouldn't be many places to look for that.
January 4, 2016 at 1:25 pm
RonKyle (1/4/2016)
Are you sure that the connection string you were 'using in the package' was not being overridden by a config item (eg, an Environment Variable)?
Yes, I'm sure. I assumed based on some answers that maybe there was an expression or something else set in the package. The package itself is a pretty simple one so there wouldn't be many places to look for that.
If it were me, I would be going into Sherlock Holmes mode and tracking that down.
Because you are suggesting that somehow the package 'remembered' its previous connection string, or that the exact same connection string works differently depending on where it is called from.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
January 4, 2016 at 1:36 pm
As the issue is resolved and I know what to look for the next time, and I have more than enough to do, going into Sherlock Holmes mode would not be the best use of my time. The issue will likely have no further impact and I may not be able to find the root cause anyway. The packages were all recently upgraded from SQL 2008 to SQL 2014. If it's related to that, the forensics would be impossible to ascertain without assigning the resources to recreate the upgrade. If the issue had been noticed sooner it might have been more worthwhile. Everything is a balance.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply