Project Everett: Early Days

Saturday, 17 May 2003

My first VB.NET project has not quite reached the keyboard yet, but at least its up on the drawing board. Here's a quick run-through of the concept, design and issues I'm going to have to tackle.


Something I do all the time is monitor the changes I make to my PC. PCs are not resilient to change, although Windows XP has improved things somewhat, and so it becomes necessary to try to trace problems back to installs, upgrades and alterations. I record changes by adding entries in a small text log file. I dallied with the idea of using an Excel spreadsheet once, but that never got off the ground.

I've decided my first .NET project will be a program that manages my system changelog. It will allow me to order the change history by date or application, to work out when problems occurred, and - hopefully - simplify entry and editing. This project will be called Everett.


The first design decision was concerned the database. Everett will not have to remember that much data - after all, I won't be making thousands and thousands of changes to my PC - so it would seem natural to store the data in a text file, and edited in memory by the application. However, for the purpose of improving my knowledge of .NET, I made the decision to locate the data in an external database and not a text file. This way, I will need to learn about ADO.NET to access the database.

The database system I am choosing is the favourite of simple database solutions everywhere - the Jet database, or more commonly known as Microsoft Access. I only have a copy of Access97, but the Jet drivers are a default component in Windows, so I have access, so to speak, to the latest Jet database technology. Note, however, that Microsoft has decided to deprecate this technology in favour of MSDE, the cut-down SQL Server which is a pain-in-the-ass to install from personal experience - and trying to bundle that with any "small-time application" is unlikely to be a walk in the park.

The database design is basic, with four tables. App will hold the application list; History will be the change log; Status holds the different statuses that can be assigned to history entires; EvProperties are any global properties that describe the database. The table structure is depicted in the image below, which I made from the query designer within Visual Studio (which is why those "All Columns" entries appear).

[Everett DB Structure]

The application will consist of a standard window with a menubar at the top, although whether it will be an MDI or not (supporting multiple DBs at any one time) has not been decided yet. In the window will be shown the history, and it can be edited using context-sensitive right-click or options from the menu bar. I will not take advantage of Access-like controls that permit direct editing to the history through the displayed data, deferring to custom forms instead. I hate those controls anyway, they seem like a great idea for programmers rather than users, but I could be wrong.


First of all, the change history is shown at all times through the main window. This suggests that the entire DB is held in memory, which in turn suggests that any changes are effected twice - once to the cached data and once to the actual DB. This is an unfortunate hangover from the decision to implement a DB when a file would suffice.

I have to get to grips with using ADO.NET on the Jet database. I am currently researching ADO.NET in the so-called "connected" and "disconnected" modes and am not entirely sure which way to go. It seems obvious that this would be a connected application than a disconnected one (where instant DB access is not a given, e.g. an internet application) but I'm not ready to make the decision yet. I'm currently reading the relevant parts of the excellent Programming Visual Basic.NET by Francesco Balena. I can't wait to start using typed datasets.

I am also starting to discover some of the interesting limitations of my copy of VB.NET. This "standard edition" of Visual Studio.NET won't build DLLs for me, only standalone applications or web services. Neither does it seem to possess any database design tools which it boasts about in the help file. Even worse, I was quite unhappy to learn that the VS.NET 2002 series will not support the latest release of the .NET Framework, version 1.1, which I find absolutely astounding for an architecture built on the paradigm of increased compatibility.

Finally, I am a big advocate of automated testing and I am going to put my money where my mouth is. Automated testing should be applied at project conception, not at the conclusion stage. This means I must have the full program design ready in advance, so that all the tests can be coded before the program can be coded. It's going to be unusual to design quite so much in advance, but I think it will be of great benefit down the line. To assist in running the tests, I will be using the clean and free NUnit. I'll cover automated testing in a separate article later, after I've got a bit more experience under my belt.

Next Up

I have to design the program flow, all of the classes and methods, so that I can write the tests first. If I make some progress, I'll be sure to let you know.