Bug report #13741
Spatialite moving fields
|Affected QGIS version:||2.12.0||Regression?:||No|
|Operating System:||Windows||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||not reproducable|
|Crashes QGIS or corrupts data:||Yes||Copied to github as #:||21768|
When using spatialite database I've found strange behaviour: sometime, with no rule, fields are saved incorrectly. This is old problem, same on 2.8, maybe earlier.
This only happens when I use table with (autoincremented) primary key. In 2.8 there was workaround - use table without primary key, but it is impossible in 2.12 (related to #13482).
In example you can find fields "move left" on first two elements. Left or right move, with no rule.
#2 Updated by Jakub Kosik over 4 years ago
As I said, there is no rule. I cannot specify exact steps, but this only happens when I digitise a lot: most vertex edit, some reshape, split, add ring. Problem show up only when I hit save button.
I am restricted to share all my database, but I attached main tables export ("GeometriaDzialki" and "Zdjecia", as I noticed on polygon and line layers).
#4 Updated by Giovanni Manghi over 4 years ago
Jakub Kosik wrote:
After some research: only new added features are broken, eg. from copy-paste or split. They are displayed properly until save.
I tried to split over and over the line layer "Zdjecia" and after saves attributes tables always looks fine to me. Maybe a screencast would help understanding how to replicate the issue.
#5 Updated by Jakub Kosik over 4 years ago
It's almost impossible to replicate this issue, so there is no hope to screencast. Issue happens once in a hundred saves, but in 50 person team it happens way too often :/
PS. Main table is "GeometriaDzialki". Strange is, as I wrote in beginning - without PrimaryKey problem does not exists.
#8 Updated by Jakub Kosik over 4 years ago
Here is some screencast - only moment of save edits. After split attributes are on places. On save - move feft (one feature saved correctly, one broken).
#9 Updated by Giovanni Manghi over 4 years ago
Jakub Kosik wrote:
Not same at all - I got mess in fields of single object, not mixed with other objects. Also geometry looks unbroken (but in my project objects disappeared due to attribute defined styles).
Yes, it seems the same issue. From the other ticket "When attributes are getting mixed with other objects, it is often the record above or below in the (table)" that is what happens exactly in the screencast you posted here.
I tried again and again with the table "GeometriaDzialki" and I wasn't able to replicate.
Please test again on QGIS master and report back.
#12 Updated by Gregor Sanders over 3 years ago
- Target version set to Version 2.18
- Create a non-geometry table in a spatialite database.
Note: Any table in the Layers Panel can be added easily to a spatialite db using the Offline Editing plugin
- Begin adding records to the table and populate more fields in the second and subsequent records than in the first added record.
Note: It does not matter if the table already contains records
- Save your edits and the following behaviour should be observed:
- only those fields that are changed in the first added record will retain data in subsequent records.
- a value entered in any field not edited in the first record will be moved to the first available field in subsequent records.
- if more fields are edited in subsequent records than are edited in the first added record, data entered in the additional fields will be lost on save.
Note, and perhaps this is a key to solving the bug: This behaviour is only reproduced when editing a non-geometry table in a spatialite database, not in a regular sqlite database.
#13 Updated by Giovanni Manghi over 3 years ago
- Status changed from Reopened to Closed
Using recent QGIS releases this (and similar) issues seems to have "gone", at least I cannot replicate them anymore.
Please give it a try on 2.18.4 (the next LTR), possibly in a clean environment (no 3rd party plugins) and if again something weird happens
please report here with detailed steps. Thanks!