You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Author Name: Miles Shugar (Miles Shugar)
Original Redmine Issue: 12682
Affected QGIS version: 2.8.1
Redmine category:vectors
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.
Related issue(s): #10887 (duplicates)
Redmine related issue(s): 828
The text was updated successfully, but these errors were encountered:
Hi,
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..
closing for lack of feedback. Please reopen if necessary.
resolution was changed from to not reproducable
status_id was changed from Feedback to Closed
qgib
added
Bug
Either a bug report, or a bug fix. Let's hope for the latter!
Vectors
Related to general vector layer handling (not specific data formats)
labels
May 25, 2019
Author Name: Miles Shugar (Miles Shugar)
Original Redmine Issue: 12682
Affected QGIS version: 2.8.1
Redmine category:vectors
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.
Related issue(s): #10887 (duplicates)
Redmine related issue(s): 828
The text was updated successfully, but these errors were encountered: