Bug report #13741
Spatialite moving fields
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Data Provider/SpatiaLite | ||
| 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 |
Description
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.
History
#1
Updated by Giovanni Manghi about 9 years ago
- Crashes QGIS or corrupts data changed from No to Yes
- Category changed from Data Provider to Data Provider/SpatiaLite
- Status changed from Open to Feedback
Can you please specify the exact steps to replicate and/or attach a sample dataset?
thanks.
#2
Updated by Jakub Kosik about 9 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).
#3
Updated by Jakub Kosik about 9 years ago
After some research: only new added features are broken, eg. from copy-paste or split. They are displayed properly until save.
#4
Updated by Giovanni Manghi about 9 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 about 9 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.
#6
Updated by Giovanni Manghi about 9 years ago
see also #13298, seems the same issue.
#7
Updated by Jakub Kosik about 9 years ago
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).
#8
Updated by Jakub Kosik about 9 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).
https://www.dropbox.com/s/0a0almedvcdkqxg/MOV_0260.mp4?dl=0
#9
Updated by Giovanni Manghi almost 9 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.
#10
Updated by Giovanni Manghi over 8 years ago
- Status changed from Feedback to Closed
- Resolution set to not reproducable
closing for lack of feedback, please reopen if necessary.
#11
Updated by Jakub Kosik over 8 years ago
- Status changed from Closed to Reopened
Problem still exists in 2.14.3
I changed simple data layer into editable spatialite view - same effect of moving fields.
#12
Updated by Gregor Sanders about 8 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 7 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!