Friday, July 17, 2009

GUIDs and Global ID Fields for Related Tables in ArcPad

When working with related tables, you will often need some form of unique value to make up the Primary Key / Foreign Key relationship. This is particularly important in ArcPad, where more than likely, you will have multiple field officers collecting data at the same time.

Perhaps the most convenient way of achieving this is through the use of Global IDs and GUIDs. Both of these data types store registry style strings consisting of 36 characters enclosed in curly brackets: for example, {90A942E1-BC7C-4F1E-94D5-AACAAD24F08C}. What this means is that there are a total of 2128 possible values – which makes the likelihood of repeating a value within your database about as likely as South Africa winning the next World Cup.

What is the difference between the two? ArcGIS actively maintains the Global ID fields (i.e. when a new feature is created, a GUID value will be assigned), whereas the GUID fields are left blank. It is up to the user to maintain these fields.

So to use these in your relationship class, you need to use the Global ID in the Origin Table as the Primary Key, and have a GUID field in the Destination Table as the Foreign Key. This way, ArcGIS and ArcPad will automatically copy the Primary Key Global ID into the Foreign Key GUID field.

To explain this a bit better, let's work through an example. Let's assume that we have a relationship between a feature class 'Weeds' and a related table 'Inspections'. Here, you would:

  • Set up the feature class with the required fields
  • Set up the related table with the required fields
  • Add the Global ID field to the Weeds feature class
    • Right click on the Weeds feature class in ArcCatalog
    • Select 'Add Global IDs...'
  • Add a GUID field to the Inspections table
    • Right click on the Inspections table in ArcCatalog
    • Select Properties
    • In the Fields page, add a field called 'Weed_ID' and make it type GUID
  • Create a relationship class between the feature class and the table
    • Right click in ArcCatalog
    • Select New à Relationship Class...
    • Follow the prompts. Make the:
      • Origin Table = Weeds feature class
      • Destination Table = Inspections Table
      • Primary Key = GlobalID (Weeds feature class)
      • Foreign Key = Weed_ID (Inspection table)

Some considerations if using this approach:

  • You must use ArcPad 8 Service Pack 1 – previous versions do not support GUIDs or GlobalIDs
  • In order to check the layer out to AXF, your feature class must be a versioned SDE feature class
  • As you are working with Relationship classes and ArcSDE, you will need ArcEditor or ArcInfo licenses to check the data back in (interestingly, you can still check out with just an ArcView license)

Remember that you can always set up the relationship using standard field types (numeric, text etc.), which you will need to do if you are not using an SDE database. Some simple coding can provide you with unique values to use in the relationship.


Stace said...

I am starting with an existing set of tables that already have a user managed KEYFIELD set, so I followed the previous steps, up to the creation of the relate table. To get the GlobalID's written to my GUID field in the Destination Table, I did a many-to-one join from the Destination Table back to the Origin Table (based on my original KEYFIELD) and was able to then seed my GUID from the GlobalID using Field Calculator. After, I simply killed the original relate table and created a new one based upon the GlobalID/GUID.

Finally, make sure your GDB is registered as versioned, but without the option to "move edits to base."


Luke Paine said...

Hi Stace, thanks for the feedback - glad we could help.

rdmccannic said...

This no longer appears to work with ArcPad 10/ArcGIS 10. On checkout, it apears arcpad does NOT checkout the GlobalID field. ArcPad also is auto generating GUIDs for all GUID fields, so the functionality can be replicated using a GUID field as the primary key.

Luke said...

Hi rdmccannic - I have just created a test feature class (ArcGIS/ArcPad 10) with a single GlobalID field, and at first it did appear that the GlobalID field was not being exported. What was actually happening though is when you add the feature class into ArcMap, by default it turns the GlobalID field off (see layer properties). When you do the check out, by default the "Export only visible layers" option is selected, and hence the GlobalID field is not exported.
Changing either of these settings (i.e. the field visibility, or the export only visible fields) will solve the problem.

Luke said...

Correction to the above comment:

When you do the check out, by default the "Export only visible layers" option is selected, and hence the GlobalID field is not exported.

should have read:

When you do the check out, by default the "Export only visible FIELDS" option is selected, and hence the GlobalID field is not exported.