QGIS support for MS SQL Server 2008 – Coming Soon!


Good news!

Support for MS SQL Server 2008 in QGIS is coming soon.   A native QGIS provider for MS SQL Server is currently being worked on to make using, managing, and editing SQL Server data in QGIS just as easy as PostGIS.

The work is being sponsored by the Australian company Digital Mapping Solutions. So a very big thanks to them for this great feature!

There is no ETA on when it will be added to the main QGIS build, but the provider is currently in testing stage and hopefully will be in there soon.

So if you have been itching to try SQL Server data in QGIS, hang in there as a good solution is just around the corner.

P.S The other blog posts on this topic I used ogr, this method will still work fine after the native provider is added, however the native driver will add a nicer interface including integration into the QBrowser, better optimization for the QGIS code, and hopefully same feel as the PostGIS experience.

About these ads

12 thoughts on “QGIS support for MS SQL Server 2008 – Coming Soon!

  1. This is a good news but it’s too bad that these improvements are not made upon the current ogr driver or replacing it, it means that this provider will be qgis-only and so that the debugging and maintaining will not be factorized with other projects.

    • I understand where you are coming from and it was something that was considered when reviewing the scope of the project. However I don’t see this is as major issue as the person writing the QGIS driver is the same guy that writes and maintains the OGR MS SQL Driver, most bug fixes that are due to non-qgis things e.g logic errors; geometry parsing errors, are ported to the ogr driver also. There is also the current state of the QGIS ogr driver to consider. The QGIS OGR driver is not really designed to handle databases in a user friendly way and has limitations handling databases, the OGR driver was more designed for “files”. I suspect that this will be reviewed in the future sometime.

      I sent a email to the mailing list with the pros and cons for each approach before this project started and it was voted that a native QGIS driver was the “best” way to go. One advantage is that is closer to the QGIS code base and doesn’t rely on waiting, or depending on, certain versions of OGR allowing quicker turn around on bugs getting fixed and shipped users of QGIS. We can also provide more QGIS based optimizations for the driver which might not be possible using the OGR driver. No silver bullet I’m afraid.

      • Thanks for the reply Nathan, I didn’t knew that Tamas was behind this new driver. I hope he will be able to maintain a low delta between both of them.

  2. I agree with Jean-Roc and Nathan’s replays and my only wish is that new driver will have option to delete spatial object in MSSQL database.
    I really don’t understand one thing. MSSQL is OCG SimpleFeature compliant and therefore there is no problem to connect with OGR, FDO and similar drivers but that more then one year this option is disabled in QGIS. I really don’t know where is the problem, OGR or QGIS?

    • Yeah the new driver has delete support.

      The delete being disabled with OGR and QGIS is a bug in the OGR MS SQL Server driver with it not returning the delete capability, so QGIS doesn’t think it can delete features. I think, although haven’t checked, that if has been fixed but I’m pretty sure the author is aware of it.

  3. Mladen,
    Remember that nothing works all that great with MSSQL spatial, not even Microsofts tools. The server is OGC compliant, yes, from the spec in 2001. Add to that the fact that geometry is stored in CLR rather than native type, and you are going to have issues. Any serious data work should be done in a modern robust spatial database. That said, I too really appreciate having a connector to MSSQL as I do recommend adding spatial data to every database

    • No Time To Lose,
      I understand your concern about general spatial development and MSSQL database but you are aware that MSSQL is well accepted database with many advantages. First, there are Microsoft for support and development. Second, Express version is free to use and support spatial data types with all benefits like Standard or Enterprise version (1 core, 10GB, enough). Third, price. Fourth, many IS already use MSSQL. Fifth, recent ability to handle spatial datatypes makes MSSQL very good choice for GIS integration.
      All leads to conclusion that for small and semi complicated projects MSSQL is good enough. I know that there is a space for lot of improvments but for majority of projects and for integration with existing nonGIS systems is ideal choice.

  4. I’ve already lost years of my life because of the lack of this plugin. I don’t think I can’t express how awesome this news is.

    The future looks bright -> i gotta wear shades.

    Bring it on, please :) :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s