Package Runs but as soon as it is scheduled in SQL Server it hangs

Hi

I'm trying to get a cute FTP script running from a package that connects to a FTPS web site.

Regardless of what method I use to execute the script it runs sucessfully in Debug mode, if I import the package into Integration Services from SQL Server Management Studio it runs, however as soon as create a SQL Server job using the stored package it hangs.

I have tried an Active X, VB.Net and an Execute Process item and get the same result everytime.

I'm also getting the same problem now with a java script I'm running from an 'Execute Process' item. Runs fine until I create a job..

Has anyone experienced the same problem? I haven't a clue what is going on and the logs aren't giving me much information.

Thanks for your help

one thing to take into account is that the script will most likely run under a different security context when it is running as a job. When you debug the script it's running with your security context, when running as a job it will run under either a proxy account context or the context of the sql agent service.

This change in security context may be causing a dialog box to pop, or you may be experiencing some kind of hidden failure.

I'd suggest having a look at the script and evaluating what security context is needed for each call. After that insert some logging into the script and evaluate what statement is not returning.

Package executing error

I wrote package using Integration Services and tried execute it on Visual Studio 2003 (Visual Basic). Package was loaded, but execute method has failed without any error messages. When I tried to run it on Visual Studio 2005, execution was successful.

Codes:

Dim App As DTSLib.IDTSApplication90 = New DTSLib.Application

Dim p As DTSLib.IDTSPackage90 = App.LoadPackage("d:\temp\Package.dtsx", True, Nothing)

p.Execute()

What can be the reason of the trouble?

Thanks,

Alexander

Only one .NET runtime can live in one process. Visual Studio 2003 uses .NET 1.1, and SSIS requires .NET 2.0 - so SSIS fails if the process has already loaded .NET 1.1.

You can use config file to change the .NET version used by applications developed with .NET 1.1 and force them to use .NET 2.0, but it will break Visual Studio debugging.

So it is highly recommended to use Visual Studio 2005. In Visual Studio 2005 you can also use managed API for SSIS - in Microsoft.SqlServer.ManagedDTS assembly, which is more convinient than using interop from DTSLib.