The Channel logo


By | Mark Whitehorn 29th January 2008 00:31

Experience overcomes Microsoft's broken promises

People-unready database ready

Project Watch: Microsoft 2008 Before we go on, let's just talk briefly, in a quiet voice, about the delay to SQL Server 2008.

The major issue here is that whilst Microsoft conveniently forgets the past, most of us can still remember SQL Server 2003, er...2004, oh, actually, that was eventually 2005. So Microsoft is turning into a serial offender when it comes to slippage.

Let me quote from an article I wrote in May 2007, just after SQL Server 2008 was announced.

"I talked to Francois Ajenstat, group product manager for SQL Server. He is adamant that Microsoft has learnt from the mistakes of the past and there is an absolute commitment to release Katmai [the code name of SQL Server 2008] on time. And I for one am convinced he's right; I never doubted the commitment back in 2003, or 2004, or even 2005. Commitment is easy, it's the delivery that is traditionally challenging."

Now, in 2008, Microsoft is back-pedaling and the release date is slipping. Again. So Microsoft hasn't learned anything. Again. And the commitment has vanished. Again. But next time the big M will tell us: "We've learnt from the past, it won't happen again. You can trust us."

So does this mean that SQL Server 2008 has suddenly become a rubbish product? Of course not. This isn't about functionality, the product still has an amazing feature set. This is about trust.

Microsoft seems to be genuinely incapable of understanding that those of us who build applications have real deadlines where slippages actually matter. It is we, not Microsoft, who receive flack when projects fail to go live on schedule.

As it happens, I'm OK. I've learned from the past. I allowed for a great deal of slippage. Why didn't Microsoft? And what about those developers who didn't?

OK, rant over. Back to the project at hand. Why my interest in SQL Server 2008 spatial data? For years now, in our application, we have been collecting data that already contains a spatial element. The problem is that it's in the form of text, such as:

Fownhope, Herefordshire Thirsk, Yorkshire.

We have long needed the capability to examine over time how events spread across the UK and the rest of the world. We have users who need to answer questions like: In this time span, how many events took place within 50 miles of London? How does the mean distance of the events vary over time from, say, Dundee?

Indeed, it goes further. We believe there is significant information buried in the spatial data, but we don't even know the right questions to ask. So we want to data mine it. We can't do that unless we can position Thirsk relative to Fownhope.

Spatial data type stores position but if that was all it did, we wouldn't bother. After all, anyone can create two number columns, two text columns and store:

Latitude N/S Longitude E/W
51.07805 N 1.48518 W

So in that sense, we've been able to store the spatial data for years. What is new is that the spatial data type comes with a raft of functions that allow the data to be manipulated. In fact it's really the functions that are the killer feature, not the data type itself.

There are at least two first jobs involved in starting this project.

The first is to find a server certified to run Windows Server 2008. How can a server be certified to run an operating system that is not yet complete and may be subject to change? No manufacturer wants to give that assurance six months before an operating system launches. On the other hand, we all know that Microsoft and the hardware vendors do work very, very closely together during this phase.

In addition, new versions of operating systems cannot afford to push the hardware boundaries too far. Dell was happy to supply us with a development server , and it should arrive within the next couple of days.

The next first job is, of course, to convert the data from text to spatial, which we can do before the server arrives. But then job zero appeared because it turned out that we first had to decide exactly what latitude and longitude system to use. (What? You didn't imagine there was just one did you?)

According to those who study geodetics - the measurement and representation of the earth - our planet is an oblate spheroid, or slightly squashed sphere.

Over the years, various attempts have been made to describe our spheroid accurately and overlay a system of latitude and longitude upon it so we can all tell where we are. We considered using the latitude and longitude coordinate system used by the Ordnance Survey maps, the delightfully ethereal-sounding Airey spheroid of 1830 (tweaked in 1936 and known as OSGB36 for short).

Presently most of our locations are in the UK, but locations worldwide will eventually figure in our application, so we opted instead for the World Geodetic System 1984 (WGS84), which is in widespread use and implemented by most GPS applications.

So we are now in a position to state that King's Somborne in Hampshire is to be found at Latitude 51.07805 N and Longitude 1.48518 W.

The next question is how do we convert over 12 thousand location items - by hand?®

comment icon Read 25 comments on this article alert Send corrections


Frank Jennings

What do you do? Use manual typwriters or live in a Scottish croft? Our man advises
A rusty petrol pump at an abandoned gas station. Pic by Silvia B. Jakiello via shutterstock

Trevor Pott

Among other things, Active Directory needs an overhaul
Baby looks taken aback/shocked/affronted. Photo by Shutterstock

Kat Hall

Plans for 2 million FTTP connections in next four years 'not enough'
Microsoft CEO Satya Nadella


Suit-and-tie-wearing man tries to meditate, take deep breaths in faux yoga pose. Photo by Shutterstock
Emotional intelligence, not tech skills, is the way to woo suits
League of gentlemen poster - Tubbs and Edward at the local shop. Copyright BBC
One reselling man tells his tale of woe