Project Sputnik Solution Structure

A couple of posts ago I mentioned I would upload some screen shots of the Solution. Well here they are. Finally.

This shows the projects with the solution. You can see all the elements required, DAL Interface, the DAL, BLL, Concrete Classes and finally the Thick Client (WinForms app).

 

Focussing on the DAL, here are the DAL classes (one for each table in the DB)

 

 

And finally, the concrete classes (one for each entity)

 

 

 



Progress update

Work commitments have hampered my work on Project Sputnik recently but I am happy to say that I have made progress.

I've created the official solution and added the child projects. I have created the DAL interface class, Entity classes and DAL classes for each table in the database, created the BL layer for the Assets that enforces the BL for the two asset classes, and finally thrown a WinForms thick-client test-harness together to display the items in the DB. This isn't demo or POC code but production code.

I'll post again soon with details and screen shots.

Step 2

In keeping with my previous post about attempting the work and then blogging about it afterwards, this post details what happened when I tried to point the existing app to the new installation of SQL Express...

In the VB6 world, my app had a single class that handled data access. A true single point of contact for the database. Everything was contained in it and to move to SQL would have been simple: Change the one class to communicate with SQL and off you go.

When I started the .NET port I tried to continue in the same way but quickly realised that it just didn’t work that way anymore. I didn’t understand the subtleties of .NET and so ended up using DataSets and TableAdapters in the form designer for each form that needed it. The project had a DataSet designer that graphically defined the links between the tables and so on.

Moving away from the Access database to SQL Server was therefore going to be tedious as there were numerous places that would need to be changed and then checked. But not to be put off I gave it a go!

First off, my Development Environment is contained in a Windows 7 Virtual PC, whereas I installed SQL Express on the main OS so I can use it for both Development and Production. So, fire up the VPC, load up Visual Studio 2010 and open the current project.

To ensure that I knew that during debugging there could be no way that data was being read from Access I renamed the Access database so that all data had to come from somewhere else (SQL hopefully).

Debugging the app threw an expected error “Could not find file 'C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb'.” Sweet.

Next, the connection string that was held in the settings file was changed from “Provider=Microsoft.ACE.OLEDB.12.0;Data Source="C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb"” to “Provider=SQLOLEDB;Data Source=MainPC\SQLExpress;Initial Catalog=OfficeManager;User ID=sa;Password=<hidden>;”

Debugging the app showed it didn’t work though! As the development environment was on a Virtual PC it was unable to connect to SQL Express on the host. Using this page I had to enable remote connections to SQL Express, enable TCP/IP, set the port to 1433 and then play with Windows Firewall to open ports 1433 and 1434 in both TCP/IP and UDP.

Finally a connection!

Opening the app and reading data worked fine, although the performance was PAINFULLY slow.

Testing a data write threw an immediate error of "Incorrect syntax near '`'." Hmmm. It quickly became obvious that it was never going to work as the SQL commands embedded in the DataSetDesigner were for Access and not SQL so things like "INSERT INTO `AssetTypes` (`AssetType`) VALUES (?)" are obviously going to fail.

I can see that there is no easy way to move the current app to SQL. I’m going to have to re-create the data schema in the application from scratch and then check every point of data access.

The question is this; is it worth all the additional effort?

Probably not. I think we'll chalk this one up as a failure and move on. I'll leave the current app as it is ...

Mike's Knowledgebase

I found this post REALLY helpful and worth a couple of hours working through the tutorials. It takes you through the process of setting up a WCF web service with a JSON payload to perform CRUD operations against SQL Server, and ultimately consume the service(s) in iOS.

http://mikesknowledgebase.com/pages/Services/WebServices.htm

Overriding base form control events

This is something that's bugged me for a while, and each time I do this I hit the same problem before the "Oh Yeah!" moment occurs and I remember what I need to do. This is clearly just a problem in my head; something that isn't intuitive for me in someway.

Inherited forms in a WinForms application : overriding the base form's control events so that the base form's event code is not executed, just the code in the derived form.

It's really very simple and I don't know why I struggle with this every time, but I do. So this Blog entry is an Aide Memoire for me.

1. On the base form, select the control in the form designer and make sure the Modifier is set to Protected
2. On the base form, in the code window, mark the event handler as protected void ...

protected virtual void button1_Click( object sender, EventArgs e)
{
    MessageBox .Show( "Hello" );
}

3. On the derived form, open the designer and double-click the button to add the button1_Click event code
4. Change the new event to protected override void ...

protected override void button1_Click( object sender, EventArgs e)
{
    MessageBox .Show( "overridden" );
}

5. In the derived form's designer code, you can see that the derived form has subscribed to the Click event again. This means that the code in the derived form's _click event will get run twice - once when the base form click event calls it, and once when the derived form calls it. The fix is to remove the this.button1.Click += new System.EventHandler(this.button1_Click); line
6. If you need to run the code in the base class, you can do this:

    base .button1_Click(sender, e);

Project Inception

Boredom. That is how it started. I was sitting at my PC when I realised that I didn't have anything to do, so my mind turned to my Office Manager tool. I put my thoughts on Facebook: