Bug report #3782

char/varchar must not be saved with ASCII 0 in Spatialite after editing

Added by Sfkeller - about 12 years ago. Updated about 12 years ago.

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


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

Revision b4c7383c
Added by Jürgen Fischer about 12 years ago

fix #3782

git-svn-id: http://svn.osgeo.org/qgis/trunk/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 5160fefd
Added by Jürgen Fischer about 12 years ago

fix #3782

git-svn-id: http://svn.osgeo.org/qgis/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c


#1 Updated by Jürgen Fischer about 12 years ago

  • Resolution set to fixed
  • Status changed from Open to Closed

should be fixed in 5160fefd (SVN r15848).

Also available in: Atom PDF