Able to run packages outside Designer, but not one containing FTP task

Hi. I have read most of the threads on not being able to run packages outside the Designer, in Agent. I believe my problem is different:

I am able to run some packages with Agent. In fact, we have a couple scheduled and running every night.

However, when we try to run a package that contains an FTP task it only runs in debug mode. If we import it into our server or run it without debugging it keeps failing and giving us the now famous:

The task...... cannot run on this edition of Integration Services. It requires a higher level edition.

So, we have some packages already scheduled and running, but we can't run this specific package with the FTP task. We (two of us) have created this package in the same way we created the other ones. We have created different versions to see if one gets a hit, with no success.

Any thoughts would be greately appreciated.

Ricardo

Do you have SSIS installed on this machine (check if you have SSIS Service installed)?|||

Michael, thanks for replying.

I and a co-worker have local machines on which we design all the packages. When they run fine in debug mode we import them into a server dedicated to SQL Server 2005 and all tools/services. It contains the databases, Integration Services, Reporting Services, etc.

We have created and scheduled several packages to run over night or over the weekend. The only one that is giving us problems is this FTP package. It would work fine in debug mode. We would import it into the server and it would fail. Based on something I found in another thread I ran it on my local machine without debugging and it failed. This is the only package that fails when not in debug mode; all the other packages run fine in both modes: debug and not debug.

I assume that if we didn't have SSIS installed none of the packages would run, but we are fairly new at this.

Is the FTP task/process maybe special in some way or have a special set of requirements?

Any further help would be greatly appreciated.

|||When you run the package with FTP task on server, where you have SSIS installed - what error do you get? The problem why it fails on server is probably different than the problem why it fails on workstation in non-debug. For more details on second issue, see
http://blogs.msdn.com/michen/archive/2006/11/11/ssis-product-level-is-insufficient.aspx

A WTF moment with SSRS....

...no, 'WTF' does not stand for 'Windows Transaction Framework,' LOL. I am writing to complain about what I believe is the annoying behavior of SSRS 2005 SP1. Specifically, I am trying to invoke a very simple MS SQL Server 2005 stored procedure as the data source of a report. This stored proc has an input parameter of type bit. The corresponding report parameter is type Boolean. When prompted for an input value when running the report, I enter a 0 or a 1. Much to my dismay, the SSRS IDE raises an error along the lines of '...error encountered when converting string value to Boolean.' For sake of argument, let's say that my stored proc's parameter were of the int type. I would then be prompted for a whole number parameter value, which I would be able to enter without a problem (no string-to-integer conversion error). What does SSRS not like about passing Boolean values to a stored proc that is expecting a bit? (Is the Boolean value converted to 'TRUE' or 'FALSE' under the covers?) Please advise, or I will be forced to spell out WTF....

TIA,

mattyseltz

...OK, the problem was my own stupidity. When prompted (in the SSRS IDE) for a parameter value for the input stored procedure parameter of type bit, I should have typed either 'False' or 'True', not 0 or 1. I think that is counter-intuitive, because one would execute the stored proc in Query Analyzer using a value of 0 or 1. Oh, well....

mattyseltz

|||IF you create parameter with Boolean type it should works either with False/True or 0/1. I have some reports like you describe and I was able to use False/True or 0/1. Anyway, you solve a problem, it's a main thing :)sql

A transport-level error has occurred when receiving results from the server. - after insta

We've devoted a resource to this today, but I have to believe it's something easy that we're overlooking. The scneario is that we have a production Web application that until last weekend had a SQL 2000 back end. This weekend we installed a new instance of SQL 2005 and everything works (we tested in a sandbox environment, but someone must not have load tested enough) and never saw these exceptions.

So, after the upgrade we now receive 100's of thexe SQL excptions per day:

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)

Does anyone know what we've overlooked that's causing this issue?

Thanks for any help!

If such exceptions occur only when machines running Win2K/WinXP, you can take a look at this KB:

http://support.microsoft.com/kb/919710

If the SQL Server is running on Win2003 SP1 and all cilents may encounter such issue, try to use the regedit.exe utility to add a new DWORD value namedSynAttackProtect to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ with value data of 00000000.

|||

Joy. We found the problem today. In efforts to improve the performance of the aspnet_xxx sprocs, we added (with nolock) to many of them. This helped tremendously in SQL 2000. It killed us when moving to 2005. Removing this fromaspnet_Profile_GetProperties solved the problem. There were more things we'd found along the way after I posted this, like with health monitoring and analysis of the SQL logs, we saw that MANY of our profiles were not being decoded as they were corrupt - not being fully read from the DB. Anyway, this explains why no one else on the Web is talking about the subject, as recommended--they probably did modify their aspnet_xxx sprocs.