Recent Comments
 | Colin on Welcome to the world Harr… |
 | John on QGIS support for MS SQL Server… |
 | Hamad on Welcome to the world Harr… |
 | Ujaval on Welcome to the world Harr… |
 | miblon on Welcome to the world Harr… |
My Flickr Photos
|
Nathans QGIS and GIS blog
A blog about my adventures with QGIS and other GIS in general.
QGIS support for MS SQL Server 2008 – Coming Soon!
Posted by on January 21, 2012
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.
Advertisement
Wow! This is fantastic news! I have been waiting for this! :)
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.
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.
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
Can we get some kind of time frame for this development? 2 months? 6 months?
Thanks.