Microsoft measures up
A meter is a meter is a meter. Not
Project Watch: Microsoft 2008 The next task in rolling out our 1TB SQL Server 2008 application using Visual Studio 2008 and Windows Server 2008 is to import signed spatial data into the spatial data type. This is the code:
UPDATE tblSpatialData SET SpatialLocation = geography::STGeomFromText('POINT (' + CONVERT(nvarchar, Latitude) + ' ' + CONVERT(nvarchar, Longitude) + ')', 4326) WHERE Latitude IS NOT NULL AND Longitude IS NOT NULL
So what's it doing? We do the conversion via an intermediate - the Well-Known Text (WKT) representation of spatial data as defined by the Open Geospatial Consortium (OGC). As the Text bit suggests, this is a text string. I'm also sure that, while it is undoubtedly Well Known within the OGC, I won't be bringing it up as a topic of conversation in my local pub.
So, we have to convert the signed integers, held in a field called SpatialLocation, into a well-formed WKT string. This is what the following does:
('POINT (' + CONVERT(nvarchar, Latitude) + ' ' + CONVERT(nvarchar, Longitude) +')', 4326)
It turns two innocent integers into a WKT string of the form:
POINT (23.2343 34.4544)
WKT as a format is perfectly capable of dealing with more complex structures such as polygons. And the "4326" at the end of the conversion? The 4326 makes it quite clear that we are using good old WGS 84 . Those with an interest in the alternatives need only run:
SELECT * FROM sys.spatial_reference_systems
From this, 388 rows of alternatives are returned.
To choose one at random, 4604 is the Montserrat 1958 standard. Most of them are based on the meter, but five are based on Clarke's foot (0.304797265 of a meter), one on the Indian foot (0.304799518m) and one on the German legal meter which very, very close to, but annoyingly not exactly the same as, the common or garden meter (1.000013597m).
All of this is, I assume, meat and drink to a geographer, but it is all new territory to a humble database person like myself. It is also an eye opener. Never again will I be defensive about my profession being nerdy.
4326 is an example of a Spatial Reference ID (SRID) and the STGeomFromText() method recognizes it and treats the incoming latitude and longitude values appropriately. In past  Project Watches, I have suggested that competent IT people could write their own spatial data types, and that's true. However here, in this one method that can recognize and deal with 389 (including WGS 84) different spatial systems, you can see why it would be a great deal of work.
That's the geography related data, then, but what of SQL Server 2008 itself?
Microsoft's approach to security has become very rigorous of late, which is excellent. However, the security policy has clearly not had time to become completely integrated with the rest of the company's policies, as has been highlighted in our work with these core additions to the Microsoft stack.
As an example, Microsoft is keen that we make use of online help - so every time we used the help system Internet Explorer accessed the web. However, by default, the server is configured with IE Enhanced Security Configuration (Esc) set to "on". So all attempts to use the online help system got blocked.
You can, of course, try to add the site to the trusted sites (although this is somewhat tortuous) but it doesn't help because the help system is based upon manifold URLs. So you cannot realistically use the help system unless you disable Esc; which is what we have done. We do understand that you can have Esc "on" for the server and "off" for the workstations but in practice it is still a major inconvenience.
As a side issue, surely anyone who names a security enhancement "escape" either has a very advanced sense of humor or none at all. It is not clear which in this case.
Security aside, where are the stories of smoke, horror and woe in implementing the system on new editions of Microsoft software? You may notice that, so far, I have not said much about how the whole software stack has been running.
Remarkably, this is because - at least until now - the whole stack has been working far, far better than we'd anticipated. We have experienced no catastrophic crashes: neither the SQL Server 2008 database engine nor the Windows Sever 2008 operating system have ever crashed. On two occasions a process crashed in Visual Studio 2008, causing it to run very slowly thereafter. Both times this was cured by the time-honored practice of rebooting the server.
Given that all of the software on the machine is a community technology preview (CTP), and given the hammering it has had, I'm very pleased with this performance. I wouldn't be happy with it in production software but this is CTP. We're using it for development not production and it has proved eminently suitable for the job.®
Follow Register Developer regular Mark Whitehorn next time on Project Watch: Microsoft 2008 as he continues to roll out a spanking-new 1TB database for several thousand users on Microsoft's SQL Server 2008, Visual Studio 2008 and Windows Server 2008.