Bug report #1941

save as shapefile leads to disordered attributes (PostGIS)

Added by Horst Düster about 15 years ago. Updated about 15 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
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 #:12001

Description

1. load a postgis layer
2. save the loaded layer as shapefile
3. open attribute table

=> the resultant attributes doesn't correspond with the original attibutes from postgis layer

Release 1.2.0 and trunk

Associated revisions

Revision 6d92ae6e
Added by Jürgen Fischer about 15 years ago

fix #1941

git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@11698 c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 5d5883bc
Added by Jürgen Fischer about 15 years ago

fix #1941

git-svn-id: http://svn.osgeo.org/qgis/trunk@11698 c8812cc2-4d05-0410-92ff-de0c093fc19c

History

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

Is it just a different order of attributes or do fieldnames and content get mixed up?

#2 Updated by cmoe - about 15 years ago

Replying to [comment:2 jef]:

Is it just a different order of attributes or do fieldnames and content get mixed up?

They get mixed up.

It looks like the second column is filled with null-values, and the following columns are wrong by one place and then get mixed up by wrong data types. Chars are all zero, dates get only the year.

The layers that I tested, have the geometry column on second place, maybe there is something wrong with?

#3 Updated by Jürgen Fischer about 15 years ago

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

Replying to [comment:3 cmoe]:

The layers that I tested, have the geometry column on second place, maybe there is something wrong with?

Yes. That was it. Should be fixed in 5d5883bc (SVN r11699).

Sorry for the long delay - svn.osgeo.org was unresponsive ;)

Also available in: Atom PDF