Bug report #12682
Deleting Features from Shapefiles on Network Drives
|Affected QGIS version:||2.8.1||Regression?:||No|
|Operating System:||Windows 7||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||not reproducable|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||20789|
We are a small GIS department of 4 folks working with a shape file composed of points. We have local installs (C:) of QGIS 2.8.1 on our workstations, which run Windows 7 x64. The shape file in question is installed on a network drive.
Lately we have noticed that, only sometimes, deleting a single point causes the attributes of the remaining points to be replaced with those of the next record in the feature set. For example, say we have 3 points, all with a field called "Label." The labels of the 3 points are as follows: FOO.1, FOO.2, FOO.3. I want to delete FOO.1, so I do so using the tool in QGIS whose icon is a red trash can, either in the map canvas or in the attribute table of the layer. The point "FOO.1" is deleted from the map and the attribute table, but now the point "FOO.2" has the attributes of the point "FOO.1," and moves to the location of the deleted point. This glitch seems to cascade down the attribute table, affecting all subsequent points in the layer and moving attributes from one record to another.
In searching for similar glitches to this one, our team has discovered the documented bug #828 from 6 years prior that seems to replicate our situation.
Unfortunately, the documentation doesn't seem to suggest a solution for those folks like us who store their layers on a drive separate from the one where QGIS is installed.
I was wondering if anyone else has come across this documented bug during their workflow, and if so, they have found sustainable ways to work around it. We have come up with a temporary solution to fix the problem of "rolled back" attributes, that is, loading the table as a .csv file and manually fixing the unique IDS associated with the features to accommodate the deleted record. However, this is not a long-term solution.
If the only solution turns out to be that we need to temporarily move our layers to our local drives and only edit them there, that'd be just fine, but we want to make sure there isn't some other simpler or more elegant solution.
#1 Updated by Regis Haubourg about 5 years ago
could you share a shape example before / after editing?
Are you editing shp concurrently ? In this case, there is no other solution than moving to a relationnal database server that handles concurrent editing in transactions (postgis, oracle, mssqlserver). Even Sqlite is not multi-user enabled..