search

nakijun / qspatialite

Automatically exported from code.google.com/p/qspatialite
0 stars 0 forks source link

SQL statements are not loaded in QGIS properly - no attribute table data #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Execute a query based on joined tables (geometry in one table with a common 
id field for the join)
2. Select option 'Load in QGIS as spatial layer' before executing query
3. In QGIS:
a) open the attribute table for the new layer, 
b) or select the 'identify features' function,
c) or select the 'select features by...' function

What is the expected output? What do you see instead?
The geometry is present and visible, the records exist in the attribute table 
but 
a) all fields are listed as 'error'.
b) The 'identify features' function does not - no data is found
c) only one feature is selected irrespective of how many are within the area 
selected (and within the attribute table the selected row is marked with 
'error' in each field)

What version of the product are you using? On what operating system?
QGIS 1.8.0 ; qspatialite 6.0.5 ; Windows XP SP3

Please provide any additional information below.
This issue did not occur with the previous version (prior to the interface 
being updated) on QGIS 1.7.x - I found it a really useful plugin and generated 
a project database specifically because I could manipulate the spatial data 
(which I'd never been able to do until I found qspatialite).

I can get around this if I execute the SQL statement with the option 'create 
spatial table and load in QGIS' but I think that this then breaks the link with 
the original dataset, which makes it more of a static snapshot than a dynamic 
database.
Thanks for your great work on this plugin.

Original issue reported on code.google.com by chris.yo...@gmail.com on 11 Feb 2013 at 10:07

GoogleCodeExporter commented 9 years ago 
Solved in QSpatiaLite v 6.0.6

Please let me know if it's not the case

Original comment by romain.r...@gmail.com on 25 Feb 2013 at 11:51

GoogleCodeExporter commented 9 years ago 
I have upgraded to v6.0.6.

Unfortunately there is no change to behaviour - exactly as previously reported. 
In my case this issue is not fixed.

Thank you for taking the time to look into this. I hope you will be able to get 
this to work.

Original comment by chris.yo...@gmail.com on 27 Feb 2013 at 10:20

GoogleCodeExporter commented 9 years ago 
I can't reproduce this error at home.
Would you send me an example of your DB and SQL query ?

(Try to re-instal QSpatiaLite, because i've uploaded it twice, and you might 
have the wrong version )

Original comment by romain.r...@gmail.com on 28 Feb 2013 at 7:41

GoogleCodeExporter commented 9 years ago 
Try to add a primary key named "PKUID" to your Spatial Table.
I think this migth be the problem.

To load a spatial layer in QGIS, you must provide a Primary Key.
And the default in QSpatiaLite is "PKUID".

Original comment by romain.r...@gmail.com on 28 Feb 2013 at 7:57

GoogleCodeExporter commented 9 years ago 
Hi,

Thanks. I have reinstalled the plug-in, which made no difference... HOWEVER...

Your suggestion about PKUID was the key (so to speak!). I already had the PKUID 
primary key in my spatial table but I had not called it in the query. So as an 
experiment I added the PKUID from my spatial table to the query and it worked!

Maybe this would be obvious to others, but it wasn't to me. It makes sense why 
the other options worked - they created a PKUID in the new spatial table, which 
was then loaded into QGIS. So this might be worth adding to any documentation - 
that any query must include the primary key(s) from the spatial table(s) as 
well as the geometry field in order to load directly into QGIS. 

Thank you very much for your help with this. You are much appreciated.
Kind regards
Chris

Original comment by chris.yo...@gmail.com on 28 Feb 2013 at 1:08

GoogleCodeExporter commented 9 years ago 
Great !

i'll try to find a solution to make it mors explicit for user

Original comment by romain.r...@gmail.com on 28 Feb 2013 at 2:37