I've become a columnist for MSDN magazine and my first column is available in the online edition, Feb 2009 issue today. I'm doing a column every few months called "Under The Table", about database-centric development. The first column is about one of the most exciting (IMHO) new features in SQL Server 2008, spatial data type and indexes, and the spatial library that's part of Microsoft.SqlServer.Types. Hope you like it.

If you seem to be getting tons of my old blog entries, it's because I've gone back through all of them and added categories. All the way to 2004. This doesn't produce updates/duplicates for my blog reader, but it may produce them for yours. Available categories are listed for easy search.

I still get questions about some of this stuff (like SQLCLR error 6522 and Query Notifications) and thought it might make it more easily referenceable. I've gone through and deleted most of the "comment spam", read all of the comments again, and updated links when appropriate. I thought it was a rather interesting comment that the biggest sources of comment spam were Video Poker and performance enhancement potions (expected) and loan brokers, especially for home loans. A comment on some of the deregulated banking practices that lead to the crash, perhaps?

I also notice that I write quite a few blog entries series. I like to include lots of content and writing a 20-page blog entry really doesn't cut it. Some of those are still (I think) useful, including the ones on Spatial index sprocs, LINQ and EDM and performance, Extended Events, SQL Server Schemas and others.

Finally, be aware that I've written entries as the product develops. In the SQL Server 2005/ADO.NET 2.0 timeframe, there were major changes between betas and RTMs. The changing of the implementation details of Query Notifications and the combining of the SqlServer and SqlClient ADO.NET provider to one provider that accomodates SQLCLR and SQL Server clients were big changes. I've categorised these as well, so if you have some old code in the areas that doesn't compile or work like it should, have a look at the progression to more recent details.

Hope you find this useful.
Bob.

Categories:

For those folks who wrote comments on the blog posts and wondered why they do not appear.... they should appear now. When our new blogging software was installed (about 3 months ago or so), a new requirement appeared....I must personally *approve* (or delete) each comment; freshly posted comments will not appear. So, I'm going back to do that right now, and answer comments.

My apologies, I'm sure it looked like the blog was on "output only" mode.

Bob

Categories:

Today I came across the new SQL Server 2008 Compliance Portal. This portal has information and links to the new Compliance whitepaper and compliance scripts (the "sample files" at the bottom of the main page on the compliance portal). New features for ensuring compliance in SQL Server 2008 include Policy-Based Management, Auditing, and TDE, to name just some of the ones that come to mind.

This information fits in well with some of the talks I'll be doing at SQLConnections in Orlando in March. I'm speaking about "Practical SQL Server 2008 Security for Developers and Architects" and "Programming PBM and Data Collection with PowerShell". I'll also be doing a day-long preconference talk on spatial data/location aware apps, and a talk on programming filestreams (unrelated to compliance). Hope to see you there.

Enjoy the compliance portal!

Categories:
SQL Server 2008 | Security

When SQL Server's spatial data types were introduced, people asked "Why does every standard method begin with ST" (e.g. STIsEmpty). SQL Server docs always cite the OGC (Open Geospatial Consortium) specifications, but OGC's methods do not begin with ST. Where did it come from?

As far as I can figure the "ST" before every standard method comes from the SQL Multimedia (SQL/MM): Part 3 Spatial spec and stands for spatial-temporal. But SQL/MM prefixes standard methods with "ST_" not "ST". ESRI and IBM's DB2 spatial extender also use "ST_", and DB2 appears to use the convention of leaving the "ST_" off for non-standard methods. Oracle Spatial uses ST as of 10g (see the comments below), as well as "SDO_" for both standard and non-standard methods (stands for Spatial Data Option). Postgres Spatial uses no prefix, a la OGC.

So what's in a naming standard? Apparently, not much. One nice side-affect is that searching for "STBoundary" (no underscore), for example, gets only references to SQL Server spatial.

Yesterday a friend asked me if it was better to always use a value of GEOMETRYCOLLECTION EMPTY as an alternative to making a geometry/geography column nullable. OGC has its own concept of database NULL, that is [GEOMETRY] EMPTY, where [GEOMETRY] can be any valid geometry subtype (that is 'POINT EMPTY', 'LINESTRING EMPTY', etc). When I asked why it mattered, he said he was tired of putting ..WHERE...IS NOT NULL in every UPDATE of SQL Server spatial data type. Sounds like reason for a blog entry.

NULL is a valid value of any SQL Server data type, defining a variable without initializing it makes it NULL.
DECLARE @x int; -- value of @x is NULL
DECLARE @geog Geography -- value of @geog is NULL

According to SQL-1999 (and above) a SQL data type can have properties and methods; accessor methods and mutator methods. Calling a accessor method on a NULL variable returns NULL. Calling a mutator method on a NULL variable is an error, in SQL Server the error text is "Mutator ... cannot be called on a NULL value". If I have a table of 100000 geography instances and one row contains NULL, attempting to update that column without using WHERE..IS NOT NULL produces this error.

UPDATE dbo.Geotable SET geog.STSrid = 4326; -- error if any row contains NULL geog

EMPTY GEOGRAPHY is a different concept then NULL because OGC defines a common architecture for geography, independent of SQL. In fact, the "OpenGIS® Implementation Specification for Geographic information - Simple feature access - Part 1:Common architecture" spec does not even use the word NULL once. EMPTY can be tested with the OGC standard method IsEmpty (STIsEmpty in SQL Server), and is defined as "the empty point set ∅ for the coordinate space". Because it is not database NULL, you can call methods on it without error:

DECLARE @a geometry = 'POINT EMPTY';
SET @a.STSrid = 4326; -- works fine

Some other interesting behaviors of [GEOGRAPHY] EMPTY

declare @a geometry, @b geometry;
set @a = 'POINT EMPTY';
set @b = 'LINESTRING EMPTY';

select @a.STEquals(@b);  -- true

select @a.STDimension(); -- -1 (negative one)

select @a.STIsEmpty();  -- true, of course
select @a.STIsSimple(); -- true

-- Disjoint is true if "Intersection of @a and @b is the empty set"
select @a.STDisjoint(@b); -- 1

-- Both Within and Contains are false
select @a.STWithin(@b);  -- 0
select @a.STContains(@b);  -- 0

Some other interesting uses of [GEOGRAPHY] EMPTY

-- the boundary of a point is the empty set
declare @x geometry = 'POINT(1 1)';
select @x.STBoundary().ToString();  -- GEOMETRYCOLLECTION EMPTY

-- but the boundary of a polygon is a closed linestring
declare @y geometry = 'POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))';
select @y.STBoundary().ToString();  -- 'LINESTRING (1 1, 2 1, 2 2, 1 2, 1 1)'

-- and the boundary of a closed linestring (ring) is GEOMETRYCOLLECTION EMPTY
declare @z geometry = @y.STBoundary();
select @z.STBoundary().ToString(); -- GEOMETRYCOLLECTION EMPTY

OGC's SQL Option spec (and SQL Server) differenciates between NULL and [GEOMETRY] EMPTY. For example, in the case above, the boundary of any NULL geometry IS NULL, not EMPTY.

Should you use NULL or EMPTY as a Geometry/Geography default? Depends on the semantics that you want to enforce, but, to me, lack of a value in SQL is NULL. And you can even include a constraint that the column value may not be either or both special values. EMPTY is a good way to ensure not having to use "IS NOT NULL" in every UPDATE statement, but that's as far as it goes.

What do you think?

Theme design by Nukeation based on Jelle Druyts