Hi Sebastian et al., I gathered from the original post, that you did manage to connect each table, separately to the vector, using different layers, which I have done myself several times.
I then gathered that this was not what you ideally wanted, and you then proceeded to play with connection settings and got some errors about GRASS not recognising a column for key/cat/Schluessel? It could be that the column, though appearing to have numbers in it, wasn't actually numeric (that was the kind of error message I'd expect for such a situation). I've seen this sort of thing happen if, for example, the tables are being imported from other formats such as .csv without the column type as 'integer', 'serial' etc. Or the imported data (associated with your .shp file) did have valid column formats but those formats were not recognised by dbf. In the past, this has happened to me with a couple of number/date formats. For that particular situation where you had that error, you might be able to check/change the column format in the database... but if you are using the inbuilt dbf database, well, I found it too limiting for my purposes when playing with tables and SQL queries and moved to PostgreSQL. As another post suggested, you could move to something like this or SQlite, MySQL, or others(?) for better table/database versatility. Another issue you mentioned related to querying the vector, and not getting info back for all the layers/connections... I have recently had similar issues with the query tool in the wxGUI (python) that I've noted in a couple of posts over the last week or two. So that issue may have been separate to how you were connecting the tables (more a problem with the GUI), but I can see how you could interpret it as being a problem with the tables/connections. I'm not sure what the verdict is on this query tool issue at moment. Getting back to your original question though...I reckon Moritz' answer might have solved your original question.. I haven't yet played with v.db.join myself, thanks to Moritz for mentioning its use for this application, it might be useful for me too :-) There may also be another approach to 'joining' the tables for connecting to GRASS, if you are working in a database. You may be able to make a 'view' (akin to a temporary new table or a select statement) from both tables of interest and connect to the 'view' from GRASS... I know in PostgreSQL, a view is considered much the same as a table and a quick check in GRASS shows I can connect to a 'view', but being a view it's not actually the original data so adding/editing I don't think is possible. That in some situations might actually be a benefit though? i.e. no unanticipated data changes whilst in GRASS. safe for punters to use... ;-) Anyway, was really just throwing in my basic experiences for your info. Hope it might help you understand some of the hurdles you've come to! Regards, Shane. _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user