Using the db_1726_gustest1 test database.
Starting with a blank map.
Connection to the database using the repository.
Double-clicking the first table: dbo.BASINS adds the layer.
Dragging the second table: dbo.gus_trail_1_life_in_a_northern_town_good_luck_ to the map crashes MW5 everytime.
Nothing is written in the log file.
How can I reproduce it? I need, for example, script to create db layer or the shapefile in case it was created through import.
It's probably not related to this crash (I wasn't able to reproduce it even once). But I have issues with SRIDs in this database. There are no records in GEOMETRY_COLUMNS table, so SRIDs are stored with each geometry and can be extracted with:
SELECT [Shape].STSrid FROM streams
For basin, reaches, streams, etc. it returns value 4236, which is a) geographic system for Taiwan (really?), b) too similar to 4326 (WGS 84). Either way, 4236 or 4326, they are both geographic systems, i.e. in decimal degrees while it seems that coordinates of shapes are not. Could you please check that those values are correct?
For some other tables SRID is 0 (RegionsA for example).
There seems to be an issue with the way you can export from ArcGIS to another format. It does not copy the SRID from the source featureclass (any non-sql server datasource) to destination sql source if you do an export without explicating saying to export the srid, but copying data from any non-sql server datasource from within ArcGIS to a sql source does copy it. It sets it to zero. That is why you see some that are SRID of 0. Is it possible to assign WGS84 as the reference system if the SRID is 0?
For the streams, reaches, basin, and watershed, that is from an old dataset, and we haven't been able to trace back to the original place these layers were referenced against. I am not sure why 4236 vs 4326 was given, but I have a feeling that what happened is someone tried to assign a geographic reference system at some point and that is why it is like that. if you want, I can change all of them to WGS 84.
I've committed a fix for this one. It turned out that wrong SRID was the source of the problem after all as coordinate transformation failed at some point and it wasn't treated correctly in code. Of course would be better to set correct SRID (I believe it's neither 4236, nor 4326).
I can confirm this is fixed.