Showing posts with label flow. Show all posts
Showing posts with label flow. Show all posts

Tuesday, March 20, 2012

Custom SSIS Task Deployment

I've written several custom Control Flow and Data Flow components for SSIS. I'm trying to deploy a new Control Flow Task, however it will not show up in the "Choose Toolbox Items" window.

I have my dll's all in the right place. Because of other painful issues we have not used the GAC, and instead have put our DLL's that are referenced in the following directory: C:\program files\Microsoft SQL Server\90\DTS\Binn. This has worked fine for other custom tasks, but not for this one.

The only things that are different about this transform are the following:

1. Not only does the task inherit from Task, it also implements two interfaces that I wrote.

2. One of the assembly references is actualy an executable instead of a dll. This is unusual, but I've done it with other .NET projects and not had any trouble.

I could move the code I need from the EXE out to a DLL. If somebody knows what could be causing this please respond?

Is your task in C:\Program Files\Microsoft SQL Server\90\DTS\Tasks ? That is where the Choose Toolbox Items looks for task, or just Reset Toolbox and it will add/remove according to the valid tasks it finds in that folder.|||My task dll is in the C:\Program Files\Microsoft SQL Server\90\DTS\Tasks folder. The difference is the dll's it references are usually placed in the DTS\Binn folder. However for some reason when I added this particular task it didn't look in the Binn folder instead it looked in the Tasks folder for it's supporting dll's. When I added the supporting dll's to the Tasks folder it showed up fine in the choose toolbox items list. I'm not sure what is different from my other tasks and this one that would require the referenced dll's to be in the same folder?|||In turns out the problem didn't have to do with either the EXE or the interface implementation. When we referenced code in our other custom tasks it was only locals inside Task methods. However this time since I was implementing an interface as part of a task it needed the referenced dll's at the time Visual Studio retrieves the list of tasks. So in addition to having the referenced dll's in the DTS/Binn folder I needed them in the DTS/Tasks folder as well.

Custom SSIS Task Deployment

I've written several custom Control Flow and Data Flow components for SSIS. I'm trying to deploy a new Control Flow Task, however it will not show up in the "Choose Toolbox Items" window.

I have my dll's all in the right place. Because of other painful issues we have not used the GAC, and instead have put our DLL's that are referenced in the following directory: C:\program files\Microsoft SQL Server\90\DTS\Binn. This has worked fine for other custom tasks, but not for this one.

The only things that are different about this transform are the following:

1. Not only does the task inherit from Task, it also implements two interfaces that I wrote.

2. One of the assembly references is actualy an executable instead of a dll. This is unusual, but I've done it with other .NET projects and not had any trouble.

I could move the code I need from the EXE out to a DLL. If somebody knows what could be causing this please respond?

Is your task in C:\Program Files\Microsoft SQL Server\90\DTS\Tasks ? That is where the Choose Toolbox Items looks for task, or just Reset Toolbox and it will add/remove according to the valid tasks it finds in that folder.|||My task dll is in the C:\Program Files\Microsoft SQL Server\90\DTS\Tasks folder. The difference is the dll's it references are usually placed in the DTS\Binn folder. However for some reason when I added this particular task it didn't look in the Binn folder instead it looked in the Tasks folder for it's supporting dll's. When I added the supporting dll's to the Tasks folder it showed up fine in the choose toolbox items list. I'm not sure what is different from my other tasks and this one that would require the referenced dll's to be in the same folder?|||In turns out the problem didn't have to do with either the EXE or the interface implementation. When we referenced code in our other custom tasks it was only locals inside Task methods. However this time since I was implementing an interface as part of a task it needed the referenced dll's at the time Visual Studio retrieves the list of tasks. So in addition to having the referenced dll's in the DTS/Binn folder I needed them in the DTS/Tasks folder as well.sql

Wednesday, March 7, 2012

Custom DataFlow Transformation not showing up in toolbox

I've created a custom data flow tranformation and it isn't showing up in the Tool Box Items to be added under the Data Flow Items tab (right click on tool box, 'Choose Items...', then clicked Data Flow Items).

I have done the following:

signed the assembly,

added to GAC,

copied the dll to C:\Program Files\Microsoft SQL Server\90\DTS\PipelineComponents.

It worked previously when I was just starting out, however now I cannot see it. What would cause it to not show up? Everything compiles fine. How would I determine how to fix it so that it shows up?

Apart from the component being in the GAC, there are two key steps to be taken for a custom component to be recognized by the BI Studio:

placing the binary under the folder where SSIS design time checks to enumerate pipeline components, which is at <SQL Installation Folder>\90\DTS\Pipeline Components (I'd double check this on the target machine via the reg key at the very bottom, cause it could be different on a 64bit or in a production server)

Saturday, February 25, 2012

Custom Data Flow Components, DllImport, and third party dlls

I've been having an issue with the integration of a third-party DLL into a custom data flow component.

The company sent me a C# project that generates a simple console application. The project includes a class that calls their DLL with DllImport. The console application runs fine.

I created a stand-alone class using the C# class they sent to expose the methods of their DLL. In my custom component, I'm referencing this class to pass data to and from their DLL.

The first method from that stand-alone class that my component encounters simply gets their installation path from the registry and does not use DllImport. That path retrieval works fine. The next method calls a function that is declared with DllImport. Each time the call fails with "System.DllNotFoundException = {"Unable to load DLL AMZip.dll': Exception from HRESULT: 0xE06D7363"}".

I've copied this DLL to countless locations (e.g., the PipelineComponents directory, the project/solution bin directory) and included these paths in all manner of path variables.

What am I missing here? Their DLL is not strong named (does this matter since I'm using DllImport?), my stand-alone class is, and of course, the custom component itself is. I appreciate the help.

No bites, eh? OK, is there a standard directory for C++ dlls used in custom components?|||I think the question on everyone's mind is, what does this have to do with SSIS?|||Strictly speaking, your question might be better served in a C# forum or something. While we do custom development here, this isn't a programming forum.|||

Phil Brammer wrote:

I think the question on everyone's mind is, what does this have to do with SSIS?

Thanks for giving me the opportunity to explain why I posted this question in the SSIS forum!

Like I said, the class in my sample console application hums like a sewing machine. When I try to integrate it into an SSIS component it fails by an error for which I can find no explanation and the finest .NET programmer I know can find no explanation, having not dealt much with SSIS internals. There aren't a whole lot of people on Earth who program SSIS components, but one place they can be sure to be found is on this forum.

I guess the upshot is, I'm hoping to get a suggested nugget from someone who may have been down this road before, as opposed to a cocksure question.

|||If your application is built on the .net 2.0 framework, then this shouldn't be that hard. The 1.1 framework won't work in SSIS, I believe.

Getting your DLLs registered in the GAC might also help.|||

The third-party component in question is a C DLL. It has dependencies to msvcm80.dll, msvcp80.dll, msvcr80.dll, and Microsoft.VC80.CRT.manifest. I have a wrapper class for the DLL with DllIImport statements that makes its functions available for .NET.

The question is... does SSIS look for non-.NET dependencies in the system path? They are obviously not in the GAC since they're not .NET.

I am getting an error that leads me to believe the dependencies are not found; however, they are in one of the directories in the system path. What else can I do to get SSIS to find them?

|||

I would expect SSIS to behave much like any other program. Really the SSIS package will be hosted, but I would expect system32 to be a good location. Similarly your dependencies for the C++ DLL would need to be there. You could look at the SSIS install bin folder, not the project, but is a bit unreliable as may not always use a MS host that is in that bin folder. Getting system32 to work I think would be better in the same way that we say always put .Net dependencies in the GAC to ensure the runtime can find what it needs.

So if you try or have tried system32 and it still fails, what is missing? Use Filemon to look for file not found or access denied events and see where it is really looking. http://www.microsoft.com/technet/sysinternals/default.mspx

|||Are you using Vista? Ever since I brought my applications into Vista, I get that error when I try to link any DLL other than windows API. The same applications worked fine on XP. I copied the file all over the place and used the full path when linking and it still says that. I get this problem with all languages, not just C#.|||

Solution -1

1.Copy DLLS to your application\ bin folder(Virtual Dir)

2. Then do the following in code.........before you do a pInvoke

StringBuilder LocalFolder = new StringBuilder(AppDomain.CurrentDomain.BaseDirectory);

LocalFolder.Append("bin");

Directory.SetCurrentDirectory(LocalFolder.ToString());

3. Then give security permission "modify" for the "bin" folder for the following

a. ASP.Net Machine accounts..

b. Network services

c. youself!!!!!!!!!!(ur login)..

4. Try ur luck..

This happens when u are in a comapany with strict access

DISCLAIMER...

I tested it out..works for me..may not work for u..I am not responsible for the damage caused due to this post

Soultion -2

The Administrator need to grant you access to the ASP.NET temporary directory (somewhere in the WINNT ).

DISCLAIMER...

I didn't test it out...got a clue from net..which lead to my solution..I am posting it bcos it may help other poor souls who has this problem..I am not responsible for the damage caused due to this post.

Pls exuce my weak knowledge of .net tehnologies.. I am a C++ /Windows programmer forced to do .Net deployment

Custom Data Flow Components, DllImport, and third party dlls

I've been having an issue with the integration of a third-party DLL into a custom data flow component.

The company sent me a C# project that generates a simple console application. The project includes a class that calls their DLL with DllImport. The console application runs fine.

I created a stand-alone class using the C# class they sent to expose the methods of their DLL. In my custom component, I'm referencing this class to pass data to and from their DLL.

The first method from that stand-alone class that my component encounters simply gets their installation path from the registry and does not use DllImport. That path retrieval works fine. The next method calls a function that is declared with DllImport. Each time the call fails with "System.DllNotFoundException = {"Unable to load DLL AMZip.dll': Exception from HRESULT: 0xE06D7363"}".

I've copied this DLL to countless locations (e.g., the PipelineComponents directory, the project/solution bin directory) and included these paths in all manner of path variables.

What am I missing here? Their DLL is not strong named (does this matter since I'm using DllImport?), my stand-alone class is, and of course, the custom component itself is. I appreciate the help.

No bites, eh? OK, is there a standard directory for C++ dlls used in custom components?|||I think the question on everyone's mind is, what does this have to do with SSIS?|||Strictly speaking, your question might be better served in a C# forum or something. While we do custom development here, this isn't a programming forum.|||

Phil Brammer wrote:

I think the question on everyone's mind is, what does this have to do with SSIS?

Thanks for giving me the opportunity to explain why I posted this question in the SSIS forum!

Like I said, the class in my sample console application hums like a sewing machine. When I try to integrate it into an SSIS component it fails by an error for which I can find no explanation and the finest .NET programmer I know can find no explanation, having not dealt much with SSIS internals. There aren't a whole lot of people on Earth who program SSIS components, but one place they can be sure to be found is on this forum.

I guess the upshot is, I'm hoping to get a suggested nugget from someone who may have been down this road before, as opposed to a cocksure question.

|||If your application is built on the .net 2.0 framework, then this shouldn't be that hard. The 1.1 framework won't work in SSIS, I believe.

Getting your DLLs registered in the GAC might also help.|||

The third-party component in question is a C DLL. It has dependencies to msvcm80.dll, msvcp80.dll, msvcr80.dll, and Microsoft.VC80.CRT.manifest. I have a wrapper class for the DLL with DllIImport statements that makes its functions available for .NET.

The question is... does SSIS look for non-.NET dependencies in the system path? They are obviously not in the GAC since they're not .NET.

I am getting an error that leads me to believe the dependencies are not found; however, they are in one of the directories in the system path. What else can I do to get SSIS to find them?

|||

I would expect SSIS to behave much like any other program. Really the SSIS package will be hosted, but I would expect system32 to be a good location. Similarly your dependencies for the C++ DLL would need to be there. You could look at the SSIS install bin folder, not the project, but is a bit unreliable as may not always use a MS host that is in that bin folder. Getting system32 to work I think would be better in the same way that we say always put .Net dependencies in the GAC to ensure the runtime can find what it needs.

So if you try or have tried system32 and it still fails, what is missing? Use Filemon to look for file not found or access denied events and see where it is really looking. http://www.microsoft.com/technet/sysinternals/default.mspx

|||Are you using Vista? Ever since I brought my applications into Vista, I get that error when I try to link any DLL other than windows API. The same applications worked fine on XP. I copied the file all over the place and used the full path when linking and it still says that. I get this problem with all languages, not just C#.|||

Solution -1

1.Copy DLLS to your application\ bin folder(Virtual Dir)

2. Then do the following in code.........before you do a pInvoke

StringBuilder LocalFolder = new StringBuilder(AppDomain.CurrentDomain.BaseDirectory);

LocalFolder.Append("bin");

Directory.SetCurrentDirectory(LocalFolder.ToString());

3. Then give security permission "modify" for the "bin" folder for the following

a. ASP.Net Machine accounts..

b. Network services

c. youself!!!!!!!!!!(ur login)..

4. Try ur luck..

This happens when u are in a comapany with strict access

DISCLAIMER...

I tested it out..works for me..may not work for u..I am not responsible for the damage caused due to this post

Soultion -2

The Administrator need to grant you access to the ASP.NET temporary directory (somewhere in the WINNT ).

DISCLAIMER...

I didn't test it out...got a clue from net..which lead to my solution..I am posting it bcos it may help other poor souls who has this problem..I am not responsible for the damage caused due to this post.

Pls exuce my weak knowledge of .net tehnologies.. I am a C++ /Windows programmer forced to do .Net deployment

Custom Data Flow Components, DllImport, and third party dlls

I've been having an issue with the integration of a third-party DLL into a custom data flow component.

The company sent me a C# project that generates a simple console application. The project includes a class that calls their DLL with DllImport. The console application runs fine.

I created a stand-alone class using the C# class they sent to expose the methods of their DLL. In my custom component, I'm referencing this class to pass data to and from their DLL.

The first method from that stand-alone class that my component encounters simply gets their installation path from the registry and does not use DllImport. That path retrieval works fine. The next method calls a function that is declared with DllImport. Each time the call fails with "System.DllNotFoundException = {"Unable to load DLL AMZip.dll': Exception from HRESULT: 0xE06D7363"}".

I've copied this DLL to countless locations (e.g., the PipelineComponents directory, the project/solution bin directory) and included these paths in all manner of path variables.

What am I missing here? Their DLL is not strong named (does this matter since I'm using DllImport?), my stand-alone class is, and of course, the custom component itself is. I appreciate the help.

No bites, eh? OK, is there a standard directory for C++ dlls used in custom components?|||I think the question on everyone's mind is, what does this have to do with SSIS?|||Strictly speaking, your question might be better served in a C# forum or something. While we do custom development here, this isn't a programming forum.|||

Phil Brammer wrote:

I think the question on everyone's mind is, what does this have to do with SSIS?

Thanks for giving me the opportunity to explain why I posted this question in the SSIS forum!

Like I said, the class in my sample console application hums like a sewing machine. When I try to integrate it into an SSIS component it fails by an error for which I can find no explanation and the finest .NET programmer I know can find no explanation, having not dealt much with SSIS internals. There aren't a whole lot of people on Earth who program SSIS components, but one place they can be sure to be found is on this forum.

I guess the upshot is, I'm hoping to get a suggested nugget from someone who may have been down this road before, as opposed to a cocksure question.

|||If your application is built on the .net 2.0 framework, then this shouldn't be that hard. The 1.1 framework won't work in SSIS, I believe.

Getting your DLLs registered in the GAC might also help.|||

The third-party component in question is a C DLL. It has dependencies to msvcm80.dll, msvcp80.dll, msvcr80.dll, and Microsoft.VC80.CRT.manifest. I have a wrapper class for the DLL with DllIImport statements that makes its functions available for .NET.

The question is... does SSIS look for non-.NET dependencies in the system path? They are obviously not in the GAC since they're not .NET.

I am getting an error that leads me to believe the dependencies are not found; however, they are in one of the directories in the system path. What else can I do to get SSIS to find them?

|||

I would expect SSIS to behave much like any other program. Really the SSIS package will be hosted, but I would expect system32 to be a good location. Similarly your dependencies for the C++ DLL would need to be there. You could look at the SSIS install bin folder, not the project, but is a bit unreliable as may not always use a MS host that is in that bin folder. Getting system32 to work I think would be better in the same way that we say always put .Net dependencies in the GAC to ensure the runtime can find what it needs.

So if you try or have tried system32 and it still fails, what is missing? Use Filemon to look for file not found or access denied events and see where it is really looking. http://www.microsoft.com/technet/sysinternals/default.mspx

|||Are you using Vista? Ever since I brought my applications into Vista, I get that error when I try to link any DLL other than windows API. The same applications worked fine on XP. I copied the file all over the place and used the full path when linking and it still says that. I get this problem with all languages, not just C#.|||

Solution -1

1.Copy DLLS to your application\ bin folder(Virtual Dir)

2. Then do the following in code.........before you do a pInvoke

StringBuilder LocalFolder = new StringBuilder(AppDomain.CurrentDomain.BaseDirectory);

LocalFolder.Append("bin");

Directory.SetCurrentDirectory(LocalFolder.ToString());

3. Then give security permission "modify" for the "bin" folder for the following

a. ASP.Net Machine accounts..

b. Network services

c. youself!!!!!!!!!!(ur login)..

4. Try ur luck..

This happens when u are in a comapany with strict access

DISCLAIMER...

I tested it out..works for me..may not work for u..I am not responsible for the damage caused due to this post

Soultion -2

The Administrator need to grant you access to the ASP.NET temporary directory (somewhere in the WINNT ).

DISCLAIMER...

I didn't test it out...got a clue from net..which lead to my solution..I am posting it bcos it may help other poor souls who has this problem..I am not responsible for the damage caused due to this post.

Pls exuce my weak knowledge of .net tehnologies.. I am a C++ /Windows programmer forced to do .Net deployment

Custom Data Flow Component Column Mapping Question

Hi,

I'm having my first go at developing a destination adapter which will send data to an update Web Service.

I've got some rather big gaps in my understanding. I've been following the various samples I've found on the net and have validated my mapping and picked up all the available column names and datatypes which are appearing in the Input and Output Properties tab of the Advanced Editor but I only have a tab for "Input Columns" and not "Column Mappings".

Which method defines the availble columns for the user to map?

Let me know if I haven't given enough information.

cheers

sorry - I had searched already but somehow missed this post which answered my question: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=239126&SiteID=1

I was having the same confusion about input and output, thinking that because i was creating a *destination* adapter, that I should be creating outputs not inputs [if that makes sense].

Custom Data Flow

To all the SSIS gurus,

I have a situation where I have multiple source tables, I need to populate the destination tables that have the same schema as the source ones. I dont want to do the repetitive task of creating a Dataflow for each source-destination load.

I want to create one custom dataflow component and loop through all my source tables and provide destination tables dynamically.

Is there a way to do that? Any custom data flow component out there?

Your ideas are greatly appreciated.

Regards,

ssiscoder wrote:

To all the SSIS gurus,

I have a situation where I have multiple source tables, I need to populate the destination tables that have the same schema as the source ones. I dont want to do the repetitive task of creating a Dataflow for each source-destination load.

I want to create one custom dataflow component and loop through all my source tables and provide destination tables dynamically.

Is there a way to do that? Any custom data flow component out there?

Your ideas are greatly appreciated.

Regards,

No you can't do this currently. Well, not with the out-of0the-box components anyway.

What you CAN do is build a package programatically in dotnet using the SSIS API. That dotnet code can be called from any place that can execute dotnet code. One of those places happens to be a SSIS package.

HTH.

-Jamie

|||

Thanks for the info Jamie!

Can you please post some articles here of how to go about doing the data flow part programitically?

Regards,

|||

ssiscoder wrote:

Thanks for the info Jamie!

Can you please post some articles here of how to go about doing the data flow part programitically?

Regards,

I can do better than that. here's a sample:

http://msdn2.microsoft.com/en-us/library/ms161541.aspx

-Jamie

|||

This might help as well: http://msdn2.microsoft.com/en-us/library/ms345167.aspx

-Jamie

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