Thursday, 6 September 2018

Visual Basic ... I predict a comeback!

I was recently at a fund-raiser for my son's school, and after a few bottles of wine, one of the other dad's struck up a conversation with me. Turns out he is also a programmer, and one of the all-too-common MVC full stack guys who writes in C#, Java, Angular etc ...

When I told him I was a SQL MCSE he was genuinely impressed and asked me interesting questions on SQL. I then mentioned that I am loving my hobby of writing Apps using Basic.

At the mere mention of the words "Visual Basic" ... he nearly fell off his chair!

I know this type ... I used to work with one at a former job ... He HATED Basic too. He is what I call a "code snob". Even though Microsoft Visual Basic .Net compiles to the same machine code as C#, there is still this stigma surrounding the language. Maybe they shouldn't have used the acronym "basic" ... ?

Anyway, as a happy co-incidence I stumbled upon this blog on Code Project. So to save me typing it all out, I'm just going to paste the link here ... If you're a hater of anything Basic ... please read this before calling me a beginner! 😄

And if you're looking for a really easy way to write apps for BOTH Android and iOS without owning a Mac ... try this:

Tuesday, 28 August 2018

Live your life as though everything you do is being recorded ... because it probably is!

With so much #data out there on us, there is now a profession of "data cleaners"! 

To paraphase Gary Vaynerchuk - "live your life as though everything you do is being recorded ... because it probably is"

Friday, 3 August 2018

Mobile Apps New Website Launched --


Just an addition to the previous post entitled "iOS and Android App Development!" ... we've been busy working on our new business and it's going better than we expected.

We've just launched our new website, with more information on it. To see it, please go to:

We've decided that for the next 12 months we're going to focus 100% on delivering high quality Data driven and database applications for both iOS and Android ... and only with businesses in the Sutherland Shire. This will mean we can develop good relationships with our business partners, and exceed their expectations.

Please spread the word ...

Rodney & Lisa!

Wednesday, 14 February 2018

iOS and Android App Development!


It's been a while since I've posted on this blog, but there is a reason for it (all be it a very poor one).

As if I needed anything else to do, I've been writing apps in my spare time, and am proud to say that I am getting pretty good at it.

So good in fact, that I've now released my first commercial app for both iOS and Android. It's an app which ties in to my popular Gym & Martial Arts Software package.

I'm now keen to do more development work and have put up this page on the company website. Please feel free to contact me if you have a million dollar idea!  😄

Monday, 10 July 2017

The Basics - Float or Dec?

This is my blog on databases, and as such I try and it keep it confined to IT and business. But there are parallels to my other job as a martial arts coach.

In jiu-jitsu, if you do not have solid basics, then you will lose. All the flashy moves in the world won't help if you don't know the finish.

And it's the same in the world of databases. I've worked on a few systems where the front end had all sorts of neat wizardry, but the engine was terrible. Here is one such example:

A financial controller came to be one day asking why some of her reports were out by one cent. Everything added up, but the final figure on the report was $0.01!

After looking at the database definitions, I saw the obvious (to me). The original designer had created the currency fields as floating point decimals!

And sadly, this is common. Because it's so easy to create a table (in for example Microsoft SQL server), then people who have not really grasped the intricacies of data types will do it, and quite often get it wrong.

Here is a brief example to demonstrate the issue of using Floats compared to Decimals:

(Copy paste the following into SSMS)

DECLARE @Num1 decimal(10,2), @Num2 decimal(10,2), @Num3 decimal(10,2);
SET @Num1 = 54; 
SET @Num2 = 3.1; 
SET @Num3 = 0 + @Num1 + @Num2; 
SELECT @Num3 AS TotalAsDecimal
SELECT @Num3 - @Num1 - @Num2 AS "Should be 0";


DECLARE @Num1 float, @Num2 float, @Num3 float;
SET @Num1 = 54; 
SET @Num2 = 3.1; 
SET @Num3 = 0 + @Num1 + @Num2; 
SELECT @Num3 AS TotalAsFloat
SELECT @Num3 - @Num1 - @Num2 AS "Should be 0";

Both these two blocks do the same thing, the only difference is in the datatypes.

Here are the results:

To understand why this simple mathematical example returns a "wrong" answer, I suggest you watch this great video put out by Computerphile. The presenter does a great job of explaining how floating point numbers are stored on disk, and how this error actually happens.

So, until next time .... study the basics, and get them right! If you get the basics wrong, it will be an expensive problem to fix later down the road.

Saturday, 8 April 2017

Dark Theme for SSMS

Do you work with SQL Server at night?

If you use Microsoft Visual Studio, then you're no doubt familiar with their dark theme. And if you're like me, then it's far easier on the eyes, especially at night.

But for some reason, Microsoft haven't released a dark theme for SQL Server Management Studio. Why not? Well apparently it's coming "in the future".

There is however a way you can change the default settings and make your own. It's a bit time consuming though.

So here's the good news ... I've created one and you can use it!

Here is how it looks:

dark theme 3
What do you think?

If you like it, then simply go to my website here: 
and download it for free. There are instructions on the page for you to follow to install it.

And if you don't like any of the colours, it's easy to change.


Friday, 10 March 2017

What data to store?

Sometimes the smallest mistakes can have serious side effects. And one I see very often is the mistake of storing data which can be calculated.

Here is an example of one I saw just this week in an accounting system. Can you spot the problem?

(I've removed some fields to just focus on the issue)

tblInvoiceHeader             tblInvoiceLines
InvoiceID InvoiceID
InvoiceName LineDesc
InvoiceAmount LineAmount
InvoiceTax LineTax
InvoiceTotal LineTotal

So here we have two tables - one for the Invoice Header, and one for the Invoice Lines.

And here is an example of some data. Let's assume it's a meal at a fast food restaurant or cafe.

  InvoiceID   InvoiceName   InvoiceAmount   InvoiceTax   InvoiceTotal
  100  Fred Smith       20.00     2.00      22.00

  InvoiceID   LineDesc   LineAmount   LineTax   LineTotal
   1   Hamburger      13.00     1.30    14.30
   2   Chips      4.00     0.40     4.40
   3   Drink      3.00          0.30     3.30

As you can see the lines all add up to give the total.

But ...

What if we need to change one value? Maybe the chips were meant to be $5 not $4?

Because of the way the data is stored, we need to alter the data in the LineAmount field ... AND the LineTax field ... AND the LineTotal field!

And that's not all ... !

We also now need to save the Invoice Header too! One change has completely thrown out all the data!

How should it be stored?

Well, depending on how often tax rates change, you could make an argument for keeping separate columns for the LineAmount and LineTax data. Especially in Australia where items such as food do not attract GST. But definitely the LineTotal should go.

And as for the InvoiceHeader table ... No need to have the totals on there either as a quick calculation can handle that.

This is how I recommend storing invoice data:

tblInvoiceHeader             tblInvoiceLines
InvoiceID InvoiceID
InvoiceName LineDesc

Unfortunately for the poor financial controller who has this data integrity problem, there is nothing easy can do except make sure that if an Invoice Line Item is changed, then the Tax is changed, and the Line Total is changed, and the Header record is changed too.

The lesson from this is to never store data which can be calculated from other data in the same, or related record(s).