topic Re: feature classes related to single table issue in ArcPad Questions

feature classes related to single table issue

SeanRedar — Wed, 27 Apr 2011 20:18:44 GMT

I have 4 feature classes that relate back to a single common table using relationship classes. I have no problem exporting the data to an axf file, but when I open the axf file in Studio only the first feature class retains the relate.

Re: feature classes related to single table issue

JasonTipton — Thu, 05 May 2011 15:13:35 GMT

What is the reason for this and how are you even doing it? Where is the primary Key, in the table or feature class?

Re: feature classes related to single table issue

SeanRedar — Thu, 05 May 2011 15:45:00 GMT

I am pulling the data from our Oracle/SDE server. There, I have four feature classes each with a relationship class (1 to m) to a common (shared) media table (not problems there). Each feature class has a pk that related to an fk in the media table.

Re: feature classes related to single table issue

JasonTipton — Thu, 05 May 2011 21:06:29 GMT

Why does this require 4 different feature classes? Could they not be definition queries of 1? What are you actually trying to collect and how do they relate in the real world?

Oh, wait. Hold on. I think I get it. You have a "media" table for pics and such. You could have multiple pics at 1 location therefore you need a 1:M to the media table on all of the feature classes so you have 4 fk in the "media table" instead of having Join tables because ArcPad doesn't support them...

hmm. . .

Re: feature classes related to single table issue

DanielleHartman__GISP — Fri, 27 May 2011 14:37:22 GMT

I also have a project with layers linking to a common table, but in this case there are mutiple layers connected to multiple common tables. Our old ArcPad 8 application used custom scripts to write data to the tables, and there was a lot of post-processing after check-in on the desktop.

For ArcPad 10, we wanted to take advantage of the related table functionality, so we redesigned our geodatabase schema. There are now separate copies of each table linked to each layer. During check-in, there is a simple tool that appends the data from the appropriate tables back into the master table. This was the best solution in term of record management. But the AXF file is rather large, and is running slower than the old application.

With just one table, I think a similar approach would work out well.