The recent FDO 3.3.0 release comes with beta support for MS SQL Server Spatial. Adding this provider to MapGuide 2.0.0 on Windows is as simple as copying a few DLLs and updating the XML provider registry.

You’ll have to take my word for it, but all of the layers here are coming from SQL Server 2008:

There are a couple small gotchas that I ran into.

If your data contains geometry inconsistencies (basically anything that doesn’t match OGC geometry specs) then the February CTP of SQL Server 2008 will cause spatial queries to fail. Apparently Microsoft may be relaxing this validity requirement in future CTPs, but for now if you have “invalid” geometry, you will have to modify it.

You can find these problems with the GEOM.STIsValid() function and fix them manually, or you can get SQL Server to “fix” the problems with a statement like this:

update dbo.YOURTABLE set GEOM = GEOM.MakeValid();

The second issue was a defect in the provider that causes spatial filters to fail if you set the SRID (spatial reference) on your data. This is because with SQL Server 2008 the SRID of the filter geometry has to match that of the database, and the provider is not setting a SRID for the filter geometry.

For now, you can work around this by removing the SRID from your features with a statement like this:

update dbo.NAN_PARCELS set GEOM.STSrid = 0;

Apart from these two minor glitches, the provider is looking good so far. I’m hoping to get a chance to test it further with later releases of SQL Server 2008 and of the provider to see how well it performs.

If you get a chance to try this out and run into any further problems, please enter a good description of the problem into the FDO Trac issue tracker. The more you test now, the more likely it will work in your production environment later!

-J

P.S. Thanks to Orest at Autodesk for helping me work through these initial issues!