Calender
<<  January 2009  >>
MoTuWeThFrSaSu
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678
Wire Up

This all started off in trying to help out a fellow SSIS enthusiast, and now I have made a complete project as a sample….. catch the MSDN forum thread here.

There are many reasons why you would want to remap source columns to destination at runtime – I would not necessarily recommend this type of solution for some of your larger and more impactful data imports, but there are many cases where being able to modify the mapping metadata at runtime can be incredibly useful.

I have posted the project example in the files directory on my blog, you can download the Visual Studio 2008 project here – keep in mind that I did this in VS 2008 Team System Architecture Edition, so if you don't have this version, then you might have an issue with the unit test project attached.

This should not pose a problem for many though, as the only reason I threw the unit test in there was to provide a simple and lazy way to call into the class and perform the remapping.

This example demonstrates the following:

  • Load an existing SSIS package and indentify the source and destination components
  • Instantiate the source and destination components to read their column metadata
  • Remap a source column to a destination column
  • Save the modified SSIS package

When you open the SSISExamples solution, build it, and then either copy the DynamicRemap.dtsx file from the bin directory to your c:\ root or modify the PackageToLoad string in the CreatePackage class.

Once you call into the CreateAndRunPackage method, you will end up with a copy of the package in your root named PackageModified.dtsx.

Please feel free to e-mail me with any questions. I'll try to make a few improvements to the example when I have free time over the coming holiday, but for now, enjoy!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Posted on: October 3, 2008, 16:25 by Sid

Yes, it is odd for me to post an entry on this blog covering thread safe ways to talk to windows user controls in C#, but I was surprised at how much trolling I had to do on Google/MSN in order to piece together a complete answer, so I figured I would share my complete and final(for now) solution.

In this particular situation, I have a windows form with a tab control, with one of the tabs hosting a text box control that displays messages. This control is not initially visible to the user, yet it is instantiated during the main form construction.

The first issue to resolve was to get the logging class and other components to make thread safe calls to this control. Microsoft has a great tutorial posted about making thread safe calls to Windows forms controls, so I won't repeat that code or explanation here.

Where I had to step beyond the MSDN article was in handling the thread safe calls to a form whose handle property may or may not be created. I am not a Windows GDI expert, I barely know what it means, but one thing I did find out during this process is that I could not guarantee when the handle for the control was created, even though its constructor was called by the containing form constructor during the application start.

To handle this, there were two steps I needed to take:

  1. Ensure that the control's handle was instantiated and available on the same thread as the main UI. To do this, I simply added this line to my code following the construction of the user control on the main form: IntPtr userControlHandle = textUserControl.Handle; This ensures that the control's handle is not created on the background thread when you access properties or methods on the control in other parts of your application
  2. I next added these lines of code to my user control:

    delegate void SolveThreadingDelegate();

    public void UserControl()

{

if (this.InvokeRequired)

{

this.Invoke(new SolveThreadingDelegate (UserControl));

}

else

{

}

}

The logging pounds this control pretty well and so far I have gotten around some of the previous locking issues I experienced – it now handles well thousands of messages an hour flying at it (not all displayed on the screen at a time, but still a constant stream of information) and I have yet to have a cross thread access violation pop up.

Hopefully this helps anyone else stuck in a similar situation; if anyone has improvements, suggestions or questions, please feel free to post.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5