Joe and code

SQL Server Management Studio - SQL Azure - unknown property IsNativelyCompiled

by Joe

After creating an Azure SQL database, management studio wouldn't allow me to view the stored procedures. I got the following error:

TITLE: Microsoft SQL Server Management Studio

Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476

------------------------------ ADDITIONAL INFORMATION:

unknown property IsNativelyCompiled (Microsoft.SqlServer.Management.Sdk.Sfc)

In a local database viewing stored procedures wasn't a problem.

Installing the latest version of SQL Server Management Studio was the only solution.

Upgrade ALM 11 project to ALM 12.20

by Joe

Prerequisite - ALM 11 and 12 cannot run on the same machine. Therefore, we assume the two installations are on different machines. The instructions are also for ALM using SQL Server.

1) Backup the ALM 11 project database - remember each ALM project is actually a separate database

2) Restore the database on the new database server

3) Run the following SQL queries on the restored project database:

EXEC sp_change_users_login 'Report';
EXEC sp_change_users_login 'Update_One', 'td', 'td';

4) Take a copy of the ALM 11 project repository folder - usually C:\ProgramData\HP\ALM\repository\qc\[PROJECT DOMAIN]\[PROJECT NAME] and paste the repository folder onto the new server - using the same folder structure 

5) Make a copy of the dbid.xml file (in the new repository folder) - call it original_dbid.xml

6) Open the ALM 12.20 Site Administration and create a new empty project:

 

create ALM 12 project

7) Remove (do not delete) the newly created project in ALM 12.20:

remove ALM 12 project

8) Go to the repository folder of the newly created/removed project in ALM 12.20 - copy the dbid.xml file and paste it into the ALM 11 project repository created in 4) above.

9) Open the dbid.xml file and edit the details to match the new environment, specifically two fields:

<DB_NAME>Enter the name of the ALM 11 database name</DB_NAME>

<PHYSICAL_DIRECTORY>Ensure this matches the folder structure for the current dbid.xml file</PHYSICAL_DIRECTORY>

10) Restore the newly created ALM 12.20 project, choosing the dbid.xml file you just updated:

restore ALM 12 project

11) Verify, and Repair if necessary, the newly created ALM 12.20 project:

verify ALM 12 project

12) Finally, upgrade the newly created ALM 12.20 project. This actually converts the project to 12.20:

upgrade ALM 12 project

 

The project should now be complete and when you login to the project via the Desktop or Web client all the defects and other project artefacts should be visible.

GOF Design Patterns in C# - the Visitor pattern

by Joe

As detailed in the first post in this series

"it’s time to revisit Design Patterns - I am going to take a look back through the book and see how many are still applicable to my own experience with C#"

Next up, the Visitor pattern.

"Visitor lets you define a new operation without changing the classes of the elements on which it operates."

I am working on an ecommerce system that not surprisingly has an Order class. However, the class has two methods for displaying the Order in HTML:

ToHtml()
ToSimpleHtml()

These poorly defined methods are bad for more than one reason, but for now let's concentrate on the fact we have presentation logic inside the Order class - this violates the Single Responsibility Principle because the Order contains domain logic and shouldn't therefore be concerned with presentation too. Moreover, it violates the Open Close Principle as it causes Order to be changed every time the format of the HTML changes. And we know HTML will change quite often as styles and fashion change.

The Visitor pattern can be used to solve this problem. We can move the presentation details out of Order and into another class. To start let's make an interface called IOrderFormatter:

public interface IOrderFormatter
{
string Format(Order order); }

Format will be responsible for formatting the Order object and returning it as a string. When there are new versions of HTML they can implement IOrderFormatter. For example, we can have an OrderHtmlFormatter that creates a basic HTML version of the Order object:

public class OrderHtmlFormatter : IOrderFormatter
{
public string Format(Order order)
{
var sb = new StringBuilder();
sb.Append("<table>");
sb.Append("<tr><td colspan=2>" + Resource.OrderNumber + ":" + order.OrderNumber + "</td></tr>");
.
.
.

We can now remove the hard-coded HTML formatting in Order itself and replace that code with the following:

public string Format(IOrderFormatter formatter)
{
return formatter.Format(this);
}

Now, any time a client wants a formatted version of the Order they can inject a formatter into this method and get the format they want - Order itself doesn't know anything about that formatting code. To keep it simple I’ll make the client just a unit test:

[TestFixture]
public class TestStoreModel
{
[Test]
public void Order_Format_Returns_Html_Version_Of_Order()
{
var order = new Order();
var html = o.Format(new OrderHtmlFormatter());
.
.
.

In the real world we might use dependency injection or a Factory to determine the actual IOrderFormatter that is used.

We have created a Formatter to help remove format code from Order to maintain the Single Responsibility Principle and ensured Order is open for extension but closed for modification. We could continue with the other formats and illustrate how this change works with class hierarchies, but I think we've highlighted enough.

Verdict:

The Visitor pattern is certainly still applicable in the .NET world and I’ve used it in my recent experience. Thank you GOF...

Next up, the Factory pattern.

GOF Design Patterns in C# - the Adapter pattern

by Joe

It's 20 years since Design Patterns: Elements of Reusable Object-Oriented Software was published, yet it’s still considered a must-read book.

I was recently asked what GOF patterns I regularly use but I could only remember about four from the book – hey, it’s been a long time since I read it! Therefore, it’s time to revisit Design Patterns - I am going to take a look back through the book and see how many are still applicable to my own experience with C#. I will refuse to talk about Pizza or Shape classes, because I find these descriptions pointless - I'll write about the real world or nothing.
First up, the Adapter pattern.

"Use the Adapter pattern when you want to use an existing class, and its interface does not match the one you need."

I recently worked on a system that retrieved delivery-information from a logistics system. The original code used the following interface:

string ExecuteLogisticsCommand(string commandToExecute) {...}

This poorly defined method is bad for so many reasons, but for now let's concentrate on the fact it is difficult to use. We have to know the details of the method to know the input and output. Extreme vagueness in a method normally suggests it does too much and sure enough, after looking at the calling code, ExecuteLogisticsCommand has 5 different and distinct scenarios. As we all know a method should only do one thing, and do it well.

If a method like ExecuteLogisticsCommand cannot be modified - perhaps we don't have the source or it’s being used in a system we are not changing - the Adapter pattern can be used to transform the interface. While ExecuteLogisticsCommand is used for 5 different reasons, we’ll look at one in this example – getting delivery details. To start let's make an interface called ILogisticsSystem, with the following method:

DeliveryDetails GetDeliveryDetails(string agreementNumber, DateTime deliveryDate)

The adapter, or wrapper, will actually implement ILogisticsSystem – let’s call the adapter LegacyLogisticsSystemAdapter.

class LegacyLogisticsSystemAdapter : ILogisticsSystem
{
public DeliveryDetails GetDeliveryDetails (string agreementNumber, DateTime deliveryDate)
{
var legacy = new LegacyLogistics();
var command = string.Format("Delivery|a={0},p={1}", agreementNumber, deliveryDate);
var result = legacy.ExecuteLogisticsCommand(command);
return new DeliveryDetails (result);
} }

We’ve hidden the horrible ExecuteLogisticsCommand – hooray!

As the legacy object is created inside LegacyLogisticsSystemAdapter this is called an Object Adapter rather than Class Adapter.
New client code can now make logistics calls on LegacyLogisticsSystemAdapter; to keep it simple I’ll just make the client a console application:

class Client
{
static void Main(string[] args)
{
ILogisticsSystem adapter = new LegacyLogisticsSystemAdapter();
var result = adapter. GetDeliveryDetails ("123", DateTime.Now);
}
}

We have created an adapter to help two incompatible interfaces work together for a better client experience. We could continue with the other 4 scenarios but I think we've highlighted enough.

Verdict:

The Adapter pattern is certainly still applicable in the .NET world and I’ve used it in my recent experience. Thank you GOF...

Next up, the Visitor pattern.