Month: July 2009

T-SQL copy and clone an existing table.

Something really useful that I like in Microsoft Access, is the capacity to select and clone an object just with a menu command.

The options we have in access are:


Structure only – will copy/paste into a new table the table structure, so the index, the primary key and so on.

Structure and Data – will copy/paste everything inside a new table.

Append – will copy the data into the existing cloned object.

What can we do with SQL Server?

Of course with SQL Server we cannot simply do that, especially if we are considering to automate this process inside a script or better, inside a job.

The first idea is to use the simple script SELECT INTO in this way:

In this way we will copy: the records, the table structure but not the index or the primary keys.

We can try to use the right click command Drop and Create and then change the destination name of our table:

New Picture (9)

Finally, we can use the SSIS service and create a powerful package able to do that. In this way we can be sure we are going to clone everything and decide if we want to copy/paste also the data.

Transfer SQL Server object task. This task will do everything we need to copy and paste an object inside SQL:


We can also use some variables in order to make our task dynamic.

Pretty cool, isn’t it?


UI Validation with the MVP pattern. Part #03

As we discussed in the previous posts, MVP UI Validation 01 and MVP UI Validation 02, thanks to the Microsoft enterprise library, we can easily handle a perfect and professional UI Validation without leaving the MVP pattern in our Client applications.

Today I want to show you a final solution, that will handle in a professional way the UI validation.

The basic validation, refractor process.

In order to view what I am going to do today, you MUST read the previous articles related to the UI validation with the enterprise library. Actually we have our domain object that is in this way:


We need to do some refactoring, in order to use our validation process in a better way. First of all let’s create a new entity called ErrorResult that will contain some useful information and, of course, its custom collection.


Now let’s go back to the Domain Object entity and let’s do some refactoring. First of all we need to change the ListResults in this way:

Then we need to change the validation function. We still declare the validation results collection:

Then we verify that our custom collection is initialized:

And finally we loop the errors and we populate the custom collection in this way:

The Customer Entity and its validation attributes.

Now we can have fun and build a custom entity that will inherit from the domain object abstract class and that will implement some custom validations.

And we can do some simple test. The first test will verify that we respect the NotNull validation rule:

Note: I added a simple ToString() function in the custom error collection in order to have the entire output in one line, only for my tests …

Reflect the validation trough the Presentation layer.

Now we need to create a simple form and a custom presentation layer in order to apply the UI logic. First of all, the form. Remember to include and error component in your form:


Then this is the view:

Finally, this is the implementation of the view in our Windows Form:

I just added a couple of routines to better manage the control in my form: ClearErrors and GetControl.

Now it’s time for the presenter. This presenter will be very easy. It will have a private IView as a field and only one constructor:

I have created also a custom init routine in order to fill my form from the presenter:

And this is the routing that fill the view from the presenter:

Last is the SubmitChanges called by the view. Here is where we are running the domain validation logic:

So for each error raised by our Entity, I am going to add the error to the corresponding control in the view. If there are no errors at all, the view will be cleaned. In this way we can also enable/disable a save button for example. But it is not the purpose of this article.

The final result will be:


I hope you enjoy my series of articles, and if you have any feedback, feel free to post them on my blog.

The next series will focus on the MVVM, I have already posted something.

If you want the solution of this tutorial, it is saved in my sky drive here


Inversion of Control with NET Framework.

Today I want to break-out my series of posts about WPF to talk about an interesting design pattern. The Inversion of Control or Dependency Injection. You can find a clear definition at this address: Martin Fowler.

What is it the Dependency Injection?

The dependency injection is a way to inject some information and configuration inside an object, from another one. In this way we keep our object abstract and recyclable.


As you can see in this example, we have two concrete tasks, and each one has an execute command that is exposed by the interface IBaseTask. This will be our bridge from the interface and the concrete implementation.

Manually Dependency Injection.

Now, if we would like to run our example, manually, we should write something like this code:

And the code in each task should be something like that:

Microsoft Unity for Dependency Injection.

Microsoft Unity is an open source project done by the Microsoft patterns and practice. It can be downloaded here: and the actual version is the 1.2 present also in the enterprise library 4.1

After you install it, you will have a folder with some .dlls that you have to reference into your solution.


Now let’s go back to our project and let’s change the code in order to have Unity and not a concrete implementation of our interface.

This is the first step, but as you can notice, it’s not so far from a concrete implementation. I mean, in this way we still have to procedural declare the type we want to convert to our interface.

The next step will be to remove the type association and use a configuration file. First of all we need to declare in our app.config file the unity section:

Then we need to associate some type to our container. This is easy.

As you can see at the end, we are going to declare our IBaseTask interface. Remember always to declare the complete path otherwise Unity will search the class into the Unity namespace!!

Now let’s build a couple of custom map inside the XML file:

As you can see, we are using our Alias to declare the interface and then we are giving a custom name the our mapping. Now we can go back to our code and do some fancy operations.

Declare the configuration section and initialize the container:

Then let’s Inject a couple of objects inside our interface:

Very easy right? In our example we are going to write in a procedural way which mapping we want to use, but of course this information should be retrieved at run-time from a Database or a serialized object.

Inject property and change values at run-time.

Until now our objects were exposing an execute method that was simply printing some fixed text in the console. But we have a name property so we should change the execute method with something like that:

Now we have two ways to initialize the TaskName property value without using a procedural code inside the program. First of all we have to say that the TaskName property of each concrete implementation has a dependency:

And now we can change the configuration in this way:

We are assigning for the mapping called WalkMapping a value of “SecondTask” for the property TaskName. This solution is fine but it’s still fixed. I mean, and if I would like to change the value at run-time and I cannot access the serialization of my object?

Here is coming the second solution:

I put a couple of comments to show you what you can configure.

I hope this short article will be useful to evaluate this amazing IoC framework.

You can find the complete solution here, in my sky drive


WPF and MVVM tutorial 07, the List search.

Ok, starting from this post we are going to do something really interesting. In this episode we need to create a simple List windows, but as you will see the logic will not be so different then a one-to-many form.

This will be the final result:


The ViewModel for the List Window.

First of all we need to create the view model. The view model should have the following commands:

  1. New – Add a new Customer
  2. Save – Save all the changes we did …
  3. Edit – Edit the current selected customer
  4. Delete – Delete the current selected customer
  5. Text box and search button – to operate search activity
  6. Exit the form

Then we need to add the following objects:

  1. An observable collection for the list of customers
  2. A current customer object, but this is not mandatory …
  3. The search information we retrieve from the view, or better, the view sends to us.

The final result will be this view model class:


Let’s have a look at the View Model commands. As you know when we assign a RelayCommand, we can do it in 2 ways:

By passing with a lambda expression the corresponding action.

By passing with a lambda expression the corresponding action and a predicate (something like true/false).

So for some commands like Save or Delete we can also build a predicate action like CanSave? CanDelete? and encapsulating some validation logic inside.

So the code should look like:


The RelayCommands.

Simple command like Create a new customer:

Or something more complex like Delete a customer: