ArcPad Check Out Problems

When you check data out for use in ArcPad, the AXF file that gets generated is stamped with the source Geodatabase. This means that when you go to check that data back in, the ArcPad Data Manager for ArcMap and the ArcPad Geoprocessing tools know where the data needs to be uploaded to.

This works really well, because you do not need to place the AXF back in to the same folder that it was checked out to (as you did with previous versions of ArcPad that used shapefiles). The drawback to this is however, when the source workspace is moved: ArcPad has no way of knowing where to put the field edited data.

The simplest way of finding where the Geodatabase should be, is to load the AXF into the ArcPad Data Manager in ArcMap. The source workspace is listed on the form:

If this workspace has a really long path however, you will not be able to see the full path. The other way to find the source workspace is to view the AXF Transaction Log that is stored within the AXF (in the AXF_Properties table). To do this:

1. Open the AXF in Studio
2. Start a command window
3. Copy the SQL statement below, paste it into the window and execute it.

SELECT CONVERT(nvarchar, XML)

FROM AXF_PROPERTIES

WHERE NAME='AXF_TRANSACTION_LOG'

You will see a whole lot of text, which at first may just look like it is in Swahili or some other foreign language, but if you look closely, it is actually XML. The first tag that you will see is CHECKOUT. The third attribute of this tag is 'workspace': the value of this attribute is the source Geodatabase that the AXF was originally generated from.

This is the location that you will need to move the Geodatabase to (temporarily) to allow you to check the data back in.

Increasing the length of a text field in a File Geodatabase

I was recently working on a job where I needed to increase the length of a text field of a feature class in a File Geodatabase. Similarly to changing the type of a field, this was not as straightforward as you might think. The process I went through was:

1. Create a temporary field to store the values of existing features
2. Delete the original field
3. Create a new field, with the increased length (using the same name as the original)
4. Copy the values from the temp field into this new field
5. Delete the temp field

So basically, a lot of work to make a very minor change. I ended up using Model Builder and writing a Python script to automate the process. Being the nice people that we are, we uploaded it to ArcScripts so anyone can download it.

If you are interested, you can download the script here.

Interested in finding out more about Model Builder? Stay tuned, RIA is currently in the process of developing an Introduction to Model Builder training course.

Field Naming Tips #2

Another tip when naming fields in a feature class, for use with ArcPad: Avoid using SQLCE reserved words.
You will find that if you do use any of these words, you will not be able to check any features in. When you select the AXF from the ArcPad Data Manager Toolbar, it will correctly list the number of features that you have created in the field (in the summary section), but then when you try to check it in, it says there are no edits in the selected layer. Unfortunately there are no error messages displayed telling you why the check in failed. I have lodged another request with ESRI, so we will see how we go in the future.
The complete list of SQLCE reserved words can be found here.

Subtype Field Names: Make them different to the feature class name

I recently had a call from a client using ArcPad 7.1, saying that their drop down lists (subtypes and coded value domains) were not appearing in ArcPad. I got a copy of their database, and performed my own check out to see what was happening.
First of all, I checked the feature class in ArcCatalog and ArcMap. All of the lists appeared as expected there.
Next I checked the .axf.xml check out log, which gets created in the same directory as the AXF file. Usually this reveals a lot about why check out was not successful, for things such as data and schema errors. Again, this was empty.
I then opened up the AXF file in ArcPad Studio, and it turned out that the Data Tables branch of the AXF structure was empty. This is where all of these tables are stored within the AXF.
After digging around for a while, I realised that the feature class was called Heritage, which was the same as the Subtype field. Turns out that this was the cause of the problem; if I renamed that field, it all worked as expected.
There are two reason for writing this blog:

1. To make you aware of the bug - I have logged this with ESRI so hopefully it will get fixed soon.
2. To outline the troubleshooting process that I went through.

Hopefully someone will find this of use. If nothing else, it should serve as a reminder for me!

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 2¹²⁸ 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.

Changing Field types in File Geodatabases

Ever tried changing the data type of a field in a feature class or table in a File Geodatabase? If you haven't, then believe me, it is not as easy as you would think. The only way of doing it is to actually create a new field and copy the values across.

As an example, let's say we want to change Field1 from an integer to a double field

1. Close ArcCatalog (it will almost definitely have a lock on the database that you can't get rid of any other way)
   
2. Rename Field1 to Field2
   
3. Create a new field called Field1 (type=double)
   
4. Copy any values across using the field calculator
   
5. Delete Field2
   

From this point on, you have to put up with Field1 being the last field in the table, which can be pretty annoying if you have spent the time setting up your feature classes in a logical order, with similar attributes situated near one another.

What is the alternative I hear you ask?

1. Export your table/feature class to a Personal Geodatabase
   
2. Open the database in Microsoft Access
   
3. Open the table in Design View
   
4. Alter the field format
   
5. Copy your table/feature class back to the file Geodatabase
   

You can also use this same method for renaming fields.

Warning! Be very cautious when doing this. Things can go wrong if you are not careful. Do not change any of the special fields (ObjectID, Shape etc.) as your table will become corrupt. You should always create a backup copy of your data before playing around with the schema of any databases.