I have a package that executes fine from the server where SQL Server in installed.
However, the below code generates an error (see below code) when executed from a workstation on the client. This is a Windows .Net application.

All other data access work just fine.

Can anyone explain this?

Bill
*********************************
Dim strMsg As String
Dim strPkgName As String
Dim oPkg As DTS.Package2

strPkgName = "PPS_BatchImport"
strDestPath = tbFileToImport.Text

oPkg = New DTS.Package2 '<--ERROR OCCURS HERE

************** Exception Text **************
System.Runtime.InteropServices.COMException (0x80040154): COM object with CLSID {10020202-EB1C-11CF-AE6E-00AA004A34D5} is either not valid or not registered.
at PPS.frmBatchImport.btnMoveToStaging_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage (Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(M essage& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

--
William R

DTS is a client side tool basically, so have your installed Enterprise
Manager or the redistributable components of DTS on the client machine?

Redistributing DTS with your program
(http://www.sqldts.com/default.aspx?225)

"WhiskRomeo" <wrlucasD0N0TSPAM (AT) Xemaps (DOT) com> wrote

registered.

Thanks for the reply.

See the previous post to this. (that was the first time I posted to this site, and I got a bogus message saying my post failed -- so I tried again)

This is a .Net applicatiion and it turns out the installer built in Visual Studio does not automatically pick the dlls related to DTS. Having to install them manually and register them defeats a main advantage of .Net application -- that is, you only need to XCopy files to the target machines. No more "dll hell."

Instead of doing that, I just kick off the DTS by running a stored procedure on the SQL SERVER. The stored procedure is initiated by the client workstation. This way there is no mess, no fuss, no messy ddl to installed and register.

Bill
--
William R


"Darren Green" wrote:

You've gone another route, and personally I prefer server side execution for
plenty of reasons, all though my top two are performance and security.

On the .Net deployment issues, you cannot expect xcopy deployment when using
COM DLLs as you are then no longer using pure managed code. Obviously this
will be a problem for some time until other products have had a chance to
embrace .Net, e.g. SQL Server 2005. Whilst the .Net setup project doesn't
detect the dependencies, you can still get it to install the DTS components,
and register them in a controlled manner along with your program.

Cheers

Darren

"WhiskRomeo" <wrlucasD0N0TSPAM (AT) Xemaps (DOT) com> wrote

install them manually and register them defeats a main advantage of .Net
application -- that is, you only need to XCopy files to the target machines.
No more "dll hell."
client workstation. This way there is no mess, no fuss, no messy ddl to
installed and register.