Spatialite moving fields

[qgib]

Author Name: Jakub Kosik (@jakosek)
Original Redmine Issue: 13741
Affected QGIS version: 2.12.0
Redmine category:data_provider/spatialite

---

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 #21527).

In example you can find fields "move left" on first two elements. Left or right move, with no rule.

---

• table.png (Jakub Kosik)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Can you please specify the exact steps to replicate and/or attach a sample dataset?

thanks.

---

• crashes_corrupts_data was changed from 0 to 1
• category_id was changed from Data Provider to Data Provider/SpatiaLite
• status_id was changed from Open to Feedback

[qgib]

Author Name: Jakub Kosik (@jakosek)

---

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).

https://www.dropbox.com/s/nzt483ditfvtoni/kontrola.rar?dl=0

[qgib]

Author Name: Jakub Kosik (@jakosek)

---

After some research: only new added features are broken, eg. from copy-paste or split. They are displayed properly until save.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Jakub Kosik (@jakosek)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

see also #21356, seems the same issue.

[qgib]

Author Name: Jakub Kosik (@jakosek)

---

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).

[qgib]

Author Name: Jakub Kosik (@jakosek)

---

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

closing for lack of feedback, please reopen if necessary.

---

• status_id was changed from Feedback to Closed
• resolution was changed from to not reproducable

[qgib]

Author Name: Jakub Kosik (@jakosek)

---

Problem still exists in 2.14.3

I changed simple data layer into editable spatialite view - same effect of moving fields.

---

• status_id was changed from Closed to Reopened

[qgib]

Author Name: Gregor Sanders (Gregor Sanders)

---

This problem can be replicated consistently with the following steps:

1. Create a non-geometry table in a spatialite database.

1. Begin adding records to the table and populate more fields in the second and subsequent records than in the first added record.

1. 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.

---

• fixed_version_id was configured as Version 2.18

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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!

---

• status_id was changed from Reopened to Closed