How about offering the ability to editing all fields in joined tables

[TimLangner]

It would be great if it were possibly to edit tables which are joined together and I don't just mean a few of the comlumns but all of the columns.

Whilst it is possible to export a joined table, in doing so the original tables are not updated and if you do a show only matching records, you lose all the other data so not much help.

The point of showing only matched records is to enable one to filter out all the unrequired records and focus on just those which match. However this does not mean that you don't want the other records, just that at this precise time you wish to focus on a subset of records that match.

When I studied database theory I don't remember there being anything which said that editing joined tables was not good practise. I believe Oracle Spatial offers it. So I think it would be great if ArcMap did as well.

There is the relate command but the results do not appear in the same table.

[TimLangner]

There is actually a simple solution to this problem and that is to create a duplicate of the table you join to.

So

Table A joins Table B
Table B cannot be edited

So create a copy of Table C called Table B_original

Now join Table A to Table_B_original.

Next do a relate rfom Table A to Table B, making sure the original join from Table A to Table B doesn't exist any more.

Then when you can view Tables A and B together for the filtering and remove data from Table B.

The only flaw is the fact Table B_original will never get updated but that may not be considered important.

[TimLangner]

Sorry that should have read create a copy of Table B called Table B_original

[JurajKrumpolec]

Maybe Parallel Edit Sessions would help.

[TimLangner]

Thanks for the link duri. That would be useful but wouldn't help in this case.

[RichardFairhurst]

With Feature classes it is possible to add one of the join FCs to a map twice.  One copy of the FCcan act as a join table and the other can act as a parent table of the join.  Definition queries should work on both the same way.  Transferring selection sets is the only problem, but select by location can deal with that partially.

For one standalone table and one feature class this should also work,  Only standalone table to standalone table would not work this way.

However, nothing will let you deal with one-to-many or many-to-many joins using ArcGIS without making a copy and performance of such joins sucks even in view only mode.  Access requires a desychronized edit mode to allow modifications of joined query tables like this, because there is delay in the update across all joins and because there is a risk that edits of a child record will not be correct when seen from another joined record.

[TimLangner]

Thanks for your reply Richard. I hadn't thought of adding the feature class twice, which I often do for display purposes or editing subsets of data.

Fortunately all my joins are one to one via id numbers I generated. I could have made them one to many if I merged various tables I created in Excel but I decided it might be more confusing when working in ArcMap and lead to more problems.

Having just one join table would work if I could do an attribute join via two matching columns, which would be required to make the list unique but I'm not sure if that can be done using ArcMap.

[TimLangner]

Of course adding a feature class twice doesn't seem to extend to attribute tables that I have exported to the SDE geodatabase. Every time I try to add one again, it does nothing. That's a shame. Oh well that's the way it goes.

[DebbieGordon]

I'm not sure if our situation is the same, but all of our attributes are stored in Oracle and joined to the spatial via layerfiles.  When we try to use Create Features with Templates none of the attributes are visible because they cannot be edited through the join.  We are therefore unable to use the Create Features with Template option and I have just determined this also precludes us from using the Production mapping extension.

[StuSmith]

The workarounds suggested in this thread are all well-intentioned, but miss the point: editing the field(s) of a joined table is a common and very useful technique - one that should NOT require a workaround!  QGIS supports this feature... just sayin'

[Bud]

@TimLangner Yes, I agree. It would be great if we could edit the fields of a joined feature class or table, all within the joined attribute table.