POST
|
Here's another take on it... (sorry, I don't know the geonet way to use code tags yet)
import arcpy
tempFC = arcpy.CreateFeatureclass_management("in_memory", "counties", "POLYGON", spatial_reference=arcpy.SpatialReference(3857)) # web mercator, eg
arcpy.AddField_management(tempFC, "Name", "TEXT")
arcpy.AddField_management(tempFC, "CountyOID", "TEXT")
countiesList = theDictionary["COUNTIES"]
with arcpy.da.InsertCursor(tempFC, ["SHAPE@", "Name", "CountyOID"]) as cur:
for county in countiesList:
outerRing = county["COUNTYRINGFEATURE"]["rings"][0]
arr = arcpy.Array()
for coordPair in outerRing:
arr.add(arcpy.Point([coordPair[0], coordPair[1]]))
polygon = arcpy.Polygon(arr)
cur.insertRow([polygon, county["COUNTY"], county["COUNTYOID"]])
... View more
12-21-2017
03:22 PM
|
2
|
2
|
1572
|
POST
|
This is getting ridiculous. There are plenty of reasons for transient disconnections on a reliable network. They are mostly user error. Eg, playing around with network settings, disconnecting cables, and most commonly (in my experience), admin users actively disconnecting users so that they can clear locks for various reasons. Maybe this doesn't happen to you, but it happens to other users. No, of course it's not possible to reject the error and remain connected. Nobody is suggesting any such thing. What would be nice (and is possible) is to handle the error gracefully. At the VERY LEAST, the application could actually report a human-readable error message that was actually related to the real underlying cause of the problem (eg, "Lost connection to database"). But more than this, the application should not require to be killed and restarted to be able to start using the data again! It's completely ridiculous! Or maybe there is some other way? The application should report a USEFUL error message, and should then let the user know the consequences (eg, you've now lost all your edits - sorry!), and give the user some options/opportunities to get back to a sane state without having to restart the entire application (which incidentally takes a crazy long time when it comes to ArcMap). IT SHOULD THEN RECONNECT TO THE DATABASE AUTOMATICALLY. Not to recover all the data/transation state, but to allow the user to re-do all the work that they've just lost. Reconnecting to databases is of course trivially easy. Even ArcGIS Server does this (after 30 minutes, by default).
... View more
10-16-2017
10:17 PM
|
0
|
1
|
1709
|
POST
|
Using database transactions on a proper RDBMS avoids that kind of corruption. A transaction makes each logical group of database operations either all-or-nothing. If the database doesn't get the 'commit' at the end of the transaction, it can roll back all of the parts of the transaction. It is always internally consistent. Corruption can of course occur for many other reasons.
... View more
10-16-2017
02:42 PM
|
0
|
0
|
1709
|
POST
|
I will have to respectfully disagree. Even on a reliable network, there are many reasons why a database can be momentarily disconnected. Other applications cope with this sort of thing fine. I appreciate that it's not simple, but it's a shame that ESRI are not even trying. Database transactions make it feasible.
... View more
10-16-2017
02:40 PM
|
0
|
3
|
1704
|
POST
|
In 2017 this is still a problem. It's a disgrace that an application in this day and age cannot recover gracefully from a brief database/network outage. It's completely insane that the software doesn't even provide an accurate, user-friendly, human-readable error message for this situation. Shame, ESRI, shame!
... View more
10-15-2017
05:23 PM
|
0
|
7
|
1704
|
Title | Kudos | Posted |
---|---|---|
2 | 12-21-2017 03:22 PM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|