Bug report #3782
char/varchar must not be saved with ASCII 0 in Spatialite after editing
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Sandro Furieri | ||
| Category: | Data Provider | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | All | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 13840 |
Description
All char/varchar values of a spatialite datasource seem to get ASCII 0 ('NUL') appended after editing with QGIS default attribute editor. This type of 'null-terminated string' does not belong here.
This turns SQL queries (like SELECT...FROM...WHERE f = 'searchstring') unusable since 'searchstring' get's compared with 'searchstring\\0'.
How to reproduce this unwanted behaviour: Create a Spatialite dataset with a table consisting of fields of type varchar and/or char. Then populate the dataset, open it in QGIS and edit a feature. After saving this feature, all values of type char/varchar get a NUL code appended. This can be visualized when exporting to CSV using Spatialite GUI tool and viewing it with a text editor.
Associated revisions
fix #3782
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@15847 c8812cc2-4d05-0410-92ff-de0c093fc19c
fix #3782
git-svn-id: http://svn.osgeo.org/qgis/trunk@15847 c8812cc2-4d05-0410-92ff-de0c093fc19c
History
#1
Updated by Jürgen Fischer almost 13 years ago
- Resolution set to fixed
- Status changed from Open to Closed
should be fixed in 5160fefd (SVN r15848).