Bug report #16020
Error saving new table records in specific field (2.99 110ffe2)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: | - | ||
| Category: | Edit widget | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Xubuntu | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | fixed/implemented |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 23935 |
Description
- The value of the "type" field is set to NULL instead of the stored value.
- An error message will be displayed at the top of the screen: "Type 12 of attribute <x> of feature <y> unknown" and the path is not displayed on the map even though the value of <type> is displayed as the same as other records which are being displayed.
These issues can be readily reproduced with the sample project supplied and following the steps below:
1. put table "OSMainSouthLine" into edit mode
2. click "Add Feature" button
3. Draw a new feature
4. Right click and add any values for the <name> and <caption> fields. for the <type> field click the drop down list and choose "Line Rail Hypothetical" from the list
5. Click OK. The new path is displayed.
6. Click the Edit pencil to take the table out of edit mode
7. Click the correct button to save the table when prompted.
8. After the edit mode is exited the new path disappears from the map.
9. Open the table and find the new record and observe: field <type> value has changed to (NULL). This will cause it to disappear from the map because of the rule based styles in effect for the map.
10. Place the table into edit mode again.
11. In field <type> use the drop down list to select Line Rail Hypothetical as the value of the field.
12. Switch back to the main Qgis window.
13. Click the Save button and you will see the error message referred to above displayed.
14. Open the table view and observe, the value of the <type> field has again been changed to (NULL).
As noted there is no issue with displaying existing records that have their <type> set to the same value. This has allowed me to work around the problem by opening the project in a VM running 2.16 in order to re-enter the <type> field values.
History
#1
Updated by Patrick Dunford over 7 years ago
So I'm seeing this adding new records to just about any table that has a field which has two things to it
- Rule based styles based on the value of that field
- A value map to select values from a drop down list for that field.
In all cases the value of the <type> field is an integer.
This has not been an issue in 2.14 through 2.18
#2
Updated by Giovanni Manghi over 7 years ago
- Category set to Edit widget
- Status changed from Open to Feedback
- Priority changed from Normal to Severe/Regression
- Target version set to Version 3.0
@kahukowhai so, to clarify: This is a regression in master about how values from a value map edit widget are written in the attribute table, correct?
Does it happens if the layer has a symbology different from rule based or the above conditions must be true both?
#3
Updated by Patrick Dunford over 7 years ago
The issue is that an error is flagged when you try to save a new record and the error occurs in the field that is used by the rule based styling on the table to generate the styles for that table. It will not allow anything except NULL to be saved in that field (so far).
Removing the value map on the field in question did not resolve the problem. There must be an issue primarily with the rule based styling.
For existing records in the table there are no problems with the style rules and the styles are correctly displayed according to those rules.
#4
Updated by Patrick Dunford over 7 years ago
- File valuemap_Main_South_Line_299.png added
- File valuemap_Main_South_Line_214.png added
There seems to be an issue with change of types from different versions of Qgis in that the description of the fields of each table has changed. I assume this has occurred as part of the project conversion which takes place upon opening a project in the new version of Qgis for the first time.
The first file attached is how the fields of the table are described in 2.14 and in the second file how they are described in 2.99. This is exactly the same table on the disk, but attached to two different project files, each of which has been saved in its respective version of Qgis.
In 2.99 what is an integer field is shows as type Qstring with a type name of Integer64. In 2.14 no such ambiguity over the type exists; it is described as type int with typename integer.
The style rules are all based on the assumption this field is an integer which it always has been described at.
I have further discovered that pasting the table style from another table will not paste the value map for this field. Normally this would be pasted.
When you enter a new record in 2.99 and set the value of this field, the new path or place or poly is displayed correctly according to the style rules; the problem is when you come to post the table. As long as the table is still in edit mode and you haven't posted the new record, it will actually be displayed on the map according to the value which is set in the field. It's only when you save the table that it spews.
#5
Updated by Patrick Dunford over 7 years ago
- File new_integer_field_299.png added
Here is the type of a new field of type integer I added in 2.99 to my table.
#6
Updated by Matthias Kuhn over 7 years ago
For me, opening the attached project shows the type qlonglong (Integer64) for the field type. Everything works as expected.
Which GDAL version is shown in Help -> About?
Are you using a 32 or 64 bit system?
#7
Updated by Patrick Dunford over 7 years ago
QGIS version
2.99.0-Master
QGIS code revision
110ffe2
Compiled against Qt
5.5.1
Running against Qt
5.5.1
Compiled against GDAL/OGR
2.1.0
Running against GDAL/OGR
2.1.0
Compiled against GEOS
3.5.0-CAPI-1.9.0
Running against GEOS
3.5.0-CAPI-1.9.0 r4084
PostgreSQL Client Version
9.5.2
SpatiaLite Version
4.3.0a
QWT Version
6.1.2
PROJ.4 Version
492
QScintilla2 Version
2.9.1
This copy of QGIS writes debugging output.
The parameter --noplugins is passed to Qgis at startup.
System: Xubuntu 16.04 64-bit
#8
Updated by Patrick Dunford over 7 years ago
I'm building a 32 bit VM same version of Xubuntu for comparison
#9
Updated by Patrick Dunford over 7 years ago
- File qgis_bug_16020_Xubuntu_1610_x86.png added
- File qgis_bug_16020_Xubuntu_1610_x86_about_qgis.png added
Attached are the results from the latest master running on Xubuntu 16.10 32 bit.
Does make it look like a 32 bit / 64 bit problem, but it is running a later master than the one on my 64 bit system.
I am currently updating my 64 bit system to the latest master for comparison.
#10
Updated by Patrick Dunford over 7 years ago
- File qgis_bug_16020_Xubuntu_1604_x64_015fdf2.png added
Here is the result from the latest master 015fdf2 on 64 bit Xubuntu
My testing so far seems to indicate the newest version of master has resolved the problem.
#11
Updated by Giovanni Manghi over 7 years ago
- Status changed from Feedback to Open
#12
Updated by Matthias Kuhn over 7 years ago
Can you shortly describe the status of your investigations?
Is this still an issue with latest master or can we close it?
#13
Updated by Giovanni Manghi over 7 years ago
- Status changed from Open to Feedback
#14
Updated by Giovanni Manghi about 7 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed/implemented
My testing so far seems to indicate the newest version of master has resolved the problem.
closing then.