Future with SSIS

Hi,

We have a NT service built via Visual Basic 6 which fires dts processes on demand according some criteria. Well, on the whole and basically only for the following rule:

-dts process is executed when our service recognize a concrete plain file leaved in a folder. It’s generally generated for a mainframe JCL along with a activator file (.nul file, empty). Each application own a folder and each folder have lots of files as the aforementioned ones. Scheduler for that is an ASP application that lives within a intranet. It also is a monitor and logger

In that schema, keeping on mind that eight out of ten are ETL processes, critical ones and on daily-basis, our question is, how to handle on with this stuff using by sql25k and its powerful SSIS? Migrating such dts packages to SSIS packages is a piece of cake (now no before; thanks Jamie, Michael and other guys for your awesome help) because of its tipology. However our main concern is what the hell to use. Centralized dtsx package running all day long as a service, listening and checking for files? .Net windows application either vb or c#? aspx solution? Set of .vbs interlinked among them?

This is a old post/goal. In spite of we have not defined any deadline for that, what the heck as time goes by is more urgent for us. A restriction: we can’t to programme nothing from our sql25k production cluster physically. Any stuff will be done on workstations.

In terms of cost, no problem at all. We are interested in hear thoughts and point of view about which is the most effective way

Thanks in advance,

I don't like packages running all day, listening for events. The architecture was not designed for that, and we have not tested packages as long running listeners.

I would suggest using SQL Server Agent, with alerts, listening for WMI messages about files arriving. See: http://msdn2.microsoft.com/en-us/library/ms191508.aspx

The alerts can execute SSIS packages using the SQL Agent SSIS subsystem.

Donald

|||Thanks a lot for your answer Donald.sql