Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

SSIS, "Class Not Registered" error...deployment or permissions issue? Expand / Collapse
Author
Message
Posted Tuesday, August 19, 2008 6:28 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, May 11, 2009 8:20 AM
Points: 3, Visits: 17
Crispin,

Thanks for your response. I tried setting the Project properties Run 64 Bit to False but I still get the same error (class not registered).

I have a similar package in which I use "Flat File Source" and load it to table (instead of using EXCEL source) and that one has no problem.

Thanks,
Post #554945
Posted Tuesday, August 19, 2008 6:55 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, July 14, 2014 3:32 PM
Points: 917, Visits: 412
can you logon to the server and run it interactivly?
If so, open CMD and set your path as "C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn" or whereever you installed SQL.

Using that dtexec, try run it. Does it run?

Are you sure the server can see the path to the file? (Was the text file in the same place?)





Cheers,
Crispin


I can't die, there are too many people who still have to meet me!

It's not a bug, SQL just misunderstood me!
Post #554961
Posted Tuesday, August 19, 2008 2:51 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 21, 2010 8:30 PM
Points: 2, Visits: 174
Sorry for my ignorance,
i cant find these options in BI.
:-(
Post #555360
Posted Tuesday, August 19, 2008 2:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, May 11, 2009 8:20 AM
Points: 3, Visits: 17
My dtexec gives error as it says WEBSERVICE cannot run with this edition. But I have requested access to this folder where the excel files exist. May be it is a permission issue, thats why it works from one folder (for flat file) but not from another (excel file). I will update you as soon as I am able to test this.

Thanks for the help on this.

Newbee - You can find options if you select Properties of Package (for 64 bit) or for Excel (for JET engine option).
Post #555364
Posted Wednesday, August 20, 2008 12:13 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 31, 2010 6:42 PM
Points: 146, Visits: 222
manjotk (8/18/2008)
"Changed from "Microsoft.ACE.OLEDB.12.0" to, "Microsoft.Jet.OLEDB.4.0" and all is well."

Where and how do u change it?


Actually, I just created a New Connection Manager by doing the following:
1. Right clicked in the, "Connection Manager" space.
2. Selected, "New OLE DB Connection..."
3. Clicked the, "New..." button.
4. Selected, "Microsoft Jet 4.0 OLE DB Provider" in the "Provider:" box at top and clicked OK.
5. Under, "Database file name:" I clicked the, "Browse..." button and navigated to a network share that contains the desired Access DB (making sure that the SQL Agent on the server that will schedule and execute this package has permissions to the network share).
6. In my case, the Access DB isn't password protected or anything so I just left the, "Admin" User Name and blank Password checkbox unchecked. Clicked the, "Test Connection" button (though this really isn't checking anything more than the fact that the Access DB had no User Name or Password.
7. "Ok" my way out of the dialogs and viola...new Connection Manager created.
8. Now I changed everything in my SSIS package to use the NEW Connection Manager I just created.
9. Finally, I built the package, copied the dtsx file from my SSIS project's "bin" folder to a location accessible by the SQL Agent scheduled to execute the package, created a new SQL Agent job on the scheduling server, pointed the job to the dtsx file, scheduled it, and done.


Alternatively...

I guess I could have just edited the, "Provider" portion of the "ConnectionString" property of the existing Connection Manager (the one that wasn't working because it was set to use the ACE provider.) If I had done it this way...
1. Right click on the existing Connection Manager
2. Select, "Properties"
3. In the Properties pane, changed the ConnectionString property from something like this:
Data Source=\etworkshare\mydb.mdb;Provider=Microsoft.ACE.OLEDB.12.0;
...to this:
Data Source=\etworkshare\mydb.mdb;Provider=Microsoft.Jet.OLEDB.4.0;

I didn't do it that way because I wanted to keep the original Connection Manager around in case my assumption about the Provider being the culprit was wrong.

Hope that helps.
Post #555513
Posted Wednesday, August 20, 2008 12:31 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 31, 2010 6:42 PM
Points: 146, Visits: 222
aharuray (8/19/2008)
My dtexec gives error as it says WEBSERVICE cannot run with this edition. But I have requested access to this folder where the excel files exist. May be it is a permission issue, thats why it works from one folder (for flat file) but not from another (excel file). I will update you as soon as I am able to test this.

Thanks for the help on this.

Newbee - You can find options if you select Properties of Package (for 64 bit) or for Excel (for JET engine option).


Hmmm...some suggestions:
1. Definitely confirm that the SQL Agent that will be executing the package has permission to read the Excel file.

2. Confirm that the output of the Webservice is really a good Excel file. This might be a crazy notion, but I've seen some cases where a service (not necessarily a webservice) creates an XLS file from a database, but the exported file is really some old Excel format (like 2.0 or something) such that the Jet provider was of no use. We had to change our export service to save as either CSV or TXT or some old DBF because XLS was just not right. Not sure how you'd check this...maybe open the export in Excel, save/overwrite the file making sure the XLS file-type is something newer and try your SSIS package again? Or maybe try linking to the Excel file from Access using the Jet provider? Or create a UDL on your desktop and see if you can connect to the Excel file? Just some thoughts. The point is to confirm your Excel file is good.

3. See if the JET driver is even installed on the server by creating a DSN or something to the Excel file (on th server). If it works, examine the connection string of the DSN and see how it compares to the one being created in your SSIS package.

I'm really just grabbing at straws here...hope it helps.
Post #555520
Posted Tuesday, August 26, 2008 2:43 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 12:14 PM
Points: 90, Visits: 316
I am using EXCEL in 64bit.
I am trying to import Excel into sql 2005 table.
It runs well in SSIS.
I read the posts, I set the run64bit (or something like that) to FALSE and rebuild the Solution that contained my package.
(I created the Solution (Package) using FANNY\wgaw on this sql server box (that is 64 bit).

Then I created the job using cmdexec step and
: C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe /f "F:\Fanny_MissingaDocs_Sln_Packages\FANNYMissing.dtsx" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EW

The job owner I tried: FANNY\wgaw , SA FANNY\SQLService
They all gave me the same error as the ones you guys described.
Wonder why is still happening?
Post #559206
Posted Wednesday, August 27, 2008 12:53 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, August 31, 2010 6:42 PM
Points: 146, Visits: 222
HKwai - Looks like you are going by the book so far. The only other thing I didn't catch is whether you confirmed that the SQL Agent's service account has access to the Excel file you are trying to access. If not, then your SSIS package will fail when scheduled through the SQL Agent.
Post #559372
Posted Thursday, August 28, 2008 7:40 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 12:14 PM
Points: 90, Visits: 316
Grasshopper, the excel file is on the same box as the sql server box.
The sql service agent account is a Domain\account that also has sa privilege and is a Domain Admin.

Post #560436
Posted Thursday, August 28, 2008 8:41 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Today @ 12:14 PM
Points: 90, Visits: 316
I finally solve my own problem luckily without calling Microsoft which would have charged an arm and a leg (It did took a while for me to solve this one!).
I just rebuild the SSIS solution from scratch .
The original SSIS solution was migrated (exported) from another server.
However, the new SSIS solution still uses the old DTSX package from the original solution.
There must be something that I migrated that the box didn't like.
Thanks all who tried to help me solve the problem.
Post #560533
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse