Hello,
Could someone help me with this issue? I want to transpose all the rows from a table as attribute fields in a feature class and I find it difficult to do for almost 500 tables and 500 rows in the feature class.
So practically I want to avoid doing a relationship class and move the data like this:
Table
------------------------------------------------
Type | Surface | Name |
A | 11 | Name1|
B | 12 | Name 2|
.
.
.
.
n | n | Name"n"|
And those multiple rows I want to move in a feature class and the feature class`s attribute table to become like this:
Feature | FC Surface | Type1| Surface1|Name1|Type2|Surface|Name2|..............|Type n|Surface n|Name n|
1 | 1212121 | A | 11 | Name1| B | 12 | Name2|.............| 'n' | ..... | ......... |
Hope you understand:)
Thanks,
Ionut
Solved! Go to Solution.
In general I agree. Also, if this is about creating labels from a set of related tables that have a 1:M relationship then do the technique shown in my Blog on that subject. it is fast enough and much easier to maintain the data than violating the data normalization pattern even more than you already have with 500 separate tables. My blog approach is based on a table structure exactly like what Vince suggested and can respect the subset query he suggested for each surface type so that all 500 tables can combined into a single table with 3 or 4 fields and still create the labels as though they were in a single row with many field columns (even better since it creates no wasted field columns ever and can maintain a data sort for you that is nearly impossible with columns).
Hello all
Well I solved the problem by using in a model a tool named "Pivot Tabel" - this tool practically transposed all my rows in columns which is all I needed. After that I merged all the tables that were "pivoted" and after that managed to join that 1 table resulted to the feature class
Thank you very much for the responses and fast feedback,
Ionut
Re : are tables really feature classes?
in a review of geodatabse fundamentals:
---as was said earlier, the geographic representation of an object - feature is stored as one of its columns (fields) in the row. the name of the field might be "geometry"
----a feature class is managed in a single table
---in a feature class table each feature class is managed as a table
---one can create feature classes aka spatial tables
---one can create feature classes from xy tables
It appears that the two are not entirely interchangable but dependent on each other.
Question is: Is the converse of the original statement true, false or utter nonsense?