Bug report #20276
Updated by Giovanni Manghi about 6 years ago
*New description:*
On the checkout - If I use Geopackage I get a "shift" of attributes. I have included a screenshot named Pre-Checkout.png . When I check out the data the attributes move one column to the right. I included a screenshot for postcheckout.png. If you look at the two screenshots - all the attributes have moved columns.
https://issues.qgis.org/issues/20276#note-2
*Old description:*
I have a postgis database and the client is wanting to use the offline editing functionality. When I checkout a layer into a geopackage in 3.4 I noticed that there is a fid column added - but in adding the column it's shoving all the attribution over one column so the attribute no longer matches the column (for instance seg_side should contain either 'L' or 'R' and doesn't now).
If I take a layer offline into spatialite I'm having to manually fill out the primary key BUT the layer columns stay intact. Which manually filling out that is going to screw up the database on check-in.
I didn't try this in 3.2. I may try shortly if I get some time. So I have no idea if this is a regression or not.
I have attached a link to the original database in case something can be wrong there. It's a pd_dump and is 24mb so I've placed it in Dropbox: https://www.dropbox.com/s/67z5dn196497bev/hc911.backup?dl=0. It can be restored using psql -d <database> -f hc911.backup
On the checkout - If I use Geopackage I get a "shift" of attributes. I have included a screenshot named Pre-Checkout.png . When I check out the data the attributes move one column to the right. I included a screenshot for postcheckout.png. If you look at the two screenshots - all the attributes have moved columns.
https://issues.qgis.org/issues/20276#note-2
*Old description:*
I have a postgis database and the client is wanting to use the offline editing functionality. When I checkout a layer into a geopackage in 3.4 I noticed that there is a fid column added - but in adding the column it's shoving all the attribution over one column so the attribute no longer matches the column (for instance seg_side should contain either 'L' or 'R' and doesn't now).
If I take a layer offline into spatialite I'm having to manually fill out the primary key BUT the layer columns stay intact. Which manually filling out that is going to screw up the database on check-in.
I didn't try this in 3.2. I may try shortly if I get some time. So I have no idea if this is a regression or not.
I have attached a link to the original database in case something can be wrong there. It's a pd_dump and is 24mb so I've placed it in Dropbox: https://www.dropbox.com/s/67z5dn196497bev/hc911.backup?dl=0. It can be restored using psql -d <database> -f hc911.backup