Opened 13 years ago
Closed 13 years ago
#3782 closed bug (fixed)
char/varchar must not be saved with ASCII 0 in Spatialite after editing
| Reported by: | Sfkeller | Owned by: | esseffe |
|---|---|---|---|
| Priority: | major: does not work as expected | Milestone: | Version 1.7.0 |
| Component: | Data Provider | Version: | Trunk |
| Keywords: | char, varchar, spatialite | Cc: | |
| Must Fix for Release: | Yes | Platform: | All |
| Platform Version: | Awaiting user input: | no |
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.
Change History (2)
comment:1 by , 13 years ago
| Owner: | changed from to |
|---|
comment:2 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
should be fixed in r15847.