Custom Control Flow Item Issue

I've been using Konesan's FileWatcher control-flow item successfully in design-mode on my PC, which runs the package on a remote server.

I have installed the Konesan's FileWatcher on the remote SQLServer machine. I then imported the package to the server (Files System folder). I then select the package, right-click 'Run Package', then Execute, and receive the error:

"Error: The task 'File Watcher Task' cannot run on this edition of Integration Services. It requires a higher level edition"

..in the 'Package Execution Progeress' dialog. All other validation seem to be ok.

(Note, I'm executing the above steps using SQLServer Mgt Studio from my PC ; I'm not doing it from the SQLServer machine itself...not sure if this matters or not.)

The SSIS version installed on the server is 9.0.3054. It shouldn't be an "SSIS version issue", as it is the same SQLServer that I used (successfully) from my PC in design mode...

Thanks,

Allen

SSIS is not likely installed on the server. Grab the installation media and verify that SSIS is installed. Better yet, look at the services on the server and see if there's a SQL Server Integration Service.|||

When you execute from SQL Server Mgt Studio, actually it runs from your system and not on server. Hence you will need SSIS installed on your box to run it locally.

This should give you some more insight

http://blogs.msdn.com/michen/archive/2006/08/11/package-exec-location.aspx

Thanks

|||Via MSSMS, I logged directly into "Integration Services", and then successfully "Import(ed) Package", so it must be installed; ObjectExpolorer shows "DEVSQL06 (Integration Services 9.0.3054...). I don't have physical access to the machine, but am having somebody checking anyway.

|||Yep, see the post above. Sorry, I missed the part about you executing the package via SSMS. *You* don't have SSIS installed on your local machine.

If you were to create an Agent job on the server that pointed to the package, it would likely work fine.|||Karunakaran - Thanks..that definitely shed some light on the topic! I thought it was being run on the server via RPC, with status messages being returned back...

I do not have any SSIS Service on my machine, so will install it. (I do have SQLServer express, but am not using it).

However, just as a test, I removed the 'FileWatcher' control, then re-imported the package to the server, and it is now running (validation's all completed, and it has "Start"ed), and I see my recordcount increasing, so it is working. How is this possible if I don't have SSIS installed?

|||Because some components need to have a full version of SSIS installed. Just try it!

It's kind of a mess the way it's setup.|||

Only some components? I was under the impression to run a SSIS package you need to have full SSIS installed.

Time to dig up and see what all component will run without full SSIS installation. Is there any document on this?

Thanks

|||
Phil

Installation of SSIS on my PC did the trick; the Konesan FileWatcher task now works!

Karunakaran

Prior to installation of SSIS (when running my package with the Konesan FileWatcher removed), the package seems to have worked just fine with the following ControlFlow items:

For Loop Container
Execute T-SQL Task
Data Flow Task
File System Task

Your help is MUCH appreciated!!!

Rgds,
Allen

Custom Control Flow Item Issue

I've been using Konesan's FileWatcher control-flow item successfully in design-mode on my PC, which runs the package on a remote server.

I have installed the Konesan's FileWatcher on the remote SQLServer machine. I then imported the package to the server (Files System folder). I then select the package, right-click 'Run Package', then Execute, and receive the error:

"Error: The task 'File Watcher Task' cannot run on this edition of Integration Services. It requires a higher level edition"

..in the 'Package Execution Progeress' dialog. All other validation seem to be ok.

(Note, I'm executing the above steps using SQLServer Mgt Studio from my PC ; I'm not doing it from the SQLServer machine itself...not sure if this matters or not.)

The SSIS version installed on the server is 9.0.3054. It shouldn't be an "SSIS version issue", as it is the same SQLServer that I used (successfully) from my PC in design mode...

Thanks,

Allen

SSIS is not likely installed on the server. Grab the installation media and verify that SSIS is installed. Better yet, look at the services on the server and see if there's a SQL Server Integration Service.|||

When you execute from SQL Server Mgt Studio, actually it runs from your system and not on server. Hence you will need SSIS installed on your box to run it locally.

This should give you some more insight

http://blogs.msdn.com/michen/archive/2006/08/11/package-exec-location.aspx

Thanks

|||Via MSSMS, I logged directly into "Integration Services", and then successfully "Import(ed) Package", so it must be installed; ObjectExpolorer shows "DEVSQL06 (Integration Services 9.0.3054...). I don't have physical access to the machine, but am having somebody checking anyway.

|||Yep, see the post above. Sorry, I missed the part about you executing the package via SSMS. *You* don't have SSIS installed on your local machine.

If you were to create an Agent job on the server that pointed to the package, it would likely work fine.|||Karunakaran - Thanks..that definitely shed some light on the topic! I thought it was being run on the server via RPC, with status messages being returned back...

I do not have any SSIS Service on my machine, so will install it. (I do have SQLServer express, but am not using it).

However, just as a test, I removed the 'FileWatcher' control, then re-imported the package to the server, and it is now running (validation's all completed, and it has "Start"ed), and I see my recordcount increasing, so it is working. How is this possible if I don't have SSIS installed?

|||Because some components need to have a full version of SSIS installed. Just try it!

It's kind of a mess the way it's setup.|||

Only some components? I was under the impression to run a SSIS package you need to have full SSIS installed.

Time to dig up and see what all component will run without full SSIS installation. Is there any document on this?

Thanks

|||
Phil

Installation of SSIS on my PC did the trick; the Konesan FileWatcher task now works!

Karunakaran

Prior to installation of SSIS (when running my package with the Konesan FileWatcher removed), the package seems to have worked just fine with the following ControlFlow items:

For Loop Container
Execute T-SQL Task
Data Flow Task
File System Task

Your help is MUCH appreciated!!!

Rgds,
Allen

Custom Application on different server than ReportServer

We are using forms authentication for our custom application. The site
connects to ReportServer and runs reports. This all works fine IF the
ReportServer is on the same webserver. If ReportServer exists on a
different web server, then we consistently get a logon ticket
authentication error.
I can confirm that the sqlAuthCookie is getting down to the browser
level, but it does not seem to get back to the server. It appears that
the ReportServer ignores the cookie and creates a new one.
Has anyone gotten this architecture to work? Both machines are on the
same network, firewalls turned off, and can see each other fine.Just in your web.config file where your asp.net code's are there, use state
server instead of InProc. This will enable to store the session and pass on
the same session variable (ie login id ) to the remote. I think the login Id
is not getting passed
to the remote server, that is why the error. Just try and let me know
whether it works.
Amarnath
"google@.landy.net" wrote:
> We are using forms authentication for our custom application. The site
> connects to ReportServer and runs reports. This all works fine IF the
> ReportServer is on the same webserver. If ReportServer exists on a
> different web server, then we consistently get a logon ticket
> authentication error.
> I can confirm that the sqlAuthCookie is getting down to the browser
> level, but it does not seem to get back to the server. It appears that
> the ReportServer ignores the cookie and creates a new one.
> Has anyone gotten this architecture to work? Both machines are on the
> same network, firewalls turned off, and can see each other fine.
>