Bug report #2819

Copied record field mismatch from shapefile to postgis

Added by bonzai - about 11 years ago. Updated about 11 years ago.

Status:Closed
Priority:Low
Assignee:Jürgen Fischer
Category:Data Provider
Affected QGIS version: Regression?:No
Operating System:Gentoo Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:12879

Description

During feature copy (using Ctrl+C Ctrl+V) between shapefile and postgis layers field's values are someway shifted.

Original SHAPEFILE feature attributes

app_id: NULL

su_id: NULL

su: 36 <-------- RIGHT

phase: NULL

date: NULL

Copied PostGIS feature attributes

app_id: NULL

su_id: 36 <--------- WRONG

su: NULL

phase: NULL

date: NULL

Associated revisions

Revision 49dc9961
Added by Jürgen Fischer about 11 years ago

fix #2819

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

Revision 34335d58
Added by Jürgen Fischer about 11 years ago

fix #2819

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

History

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

The field values are assigned in order not by name. Does the attribute order in your postgis table match the order of fields in the shapefile's dbf?

#2 Updated by bonzai - about 11 years ago

Replying to [comment:1 jef]:

The field values are assigned in order not by name. Does the attribute order in your postgis table match the order of fields in the shapefile's dbf?

Looking in layers' properties attribute tab I've found this:

SHAPEFILE

-|id|name

1|0 |app_id

2|1 |su_id

3|2 |su <-------

4|3 |phase

5|4 |date

POSTGIS

-|id|name

1|0 |app_id

2|2 |su_id

3|3 |su <-------

4|4 |phase

5|5 |date

So it seems thats records have the same order but different ids.
A further information that could you help: the shapefile is the result of 'Export as shapefile' QGIS command.

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

Might the geometry column in postgis not be the last column?

#4 Updated by bonzai - about 11 years ago

Replying to [comment:3 jef]:

Might the geometry column in postgis not be the last column?

Actually it's not a table but a view with insert,update,delete rules:

CREATE OR REPLACE VIEW dataschemaname.w_core_geom_sus AS
SELECT g.app_id, g.geom, s.app_id AS su_id, s.short_def AS su, ph.short_def AS phase, s.date
FROM dataschemaname.core_geom_sus g
LEFT JOIN dataschemaname.core_std_sus s ON g.su_id = s.app_id
LEFT JOIN dataschemaname.core_voc_phases ph ON s.phase_id = ph.app_id;

As you can see the geometry column is the second one. Should it be the last one?
It's not a big issue but I've never heard about this...

#5 Updated by bonzai - about 11 years ago

Replying to [comment:3 jef]:

Might the geometry column in postgis not be the last column?

Reoerdering view's fields putting geometry colums last works for me.
But in my opinion it's just a workaround and not a proper solution so I just changed the priority to minor.

Thanks for the quick answer

#6 Updated by Jürgen Fischer about 11 years ago

Replying to [comment:5 bonzai]:

Reoerdering view's fields putting geometry colums last works for me.
But in my opinion it's just a workaround and not a proper solution so I just changed the priority to minor.

Sure it is.

#7 Updated by Jürgen Fischer about 11 years ago

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

fixed in 34335d58 (SVN r13809).

Also available in: Atom PDF