I used OGR2OGR to import SRID 4326 point data into MSSQL Server. Didn't realize that it defaults to creating a geometry column instead of detecting the data as 4326 and creating a geography column. I know the code to get around this so no issue there.
The data as is in a geometry column shows up just fine in QGIS. So do I actually need to put the data in a geography column?
thanks!
If you do not need to measure distances over the spheroid then geometry suits well. The PostGIS manual contains understandable info about this http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#PostGIS_Geography and it is valid also for MSSQL.
I did this by accident a few months ago, although it was with lines and it was a very large featureclass (I think it was on the order of 10 million features). I also don't remember if it was SQL Server 2008 or 2012.
One thing that I noticed in ArcMap was that everything was really, really slow. I profiled it. Found the query that was causing the slowness and popped it into SSMS and determined that it was the Filter method that was the culprit (iirc, ArcMap uses Filter with an envelope to grab OIDs). SQL Server was bringing back every single row in the table!!
When I switched over to geography, Filter was returning the correct number of features for the given geometry.
I don't recall other methods behaving badly, but I didn't leave the 4326 data in SQL geometry long enough to find out.
If your table size is not very large, this might not matter. But its something to keep in mind for larger tables. It also wouldn't matter if QGIS doesn't use Filter.
