Bug Report: Bug with axf Files Confirmed in ArcPad 10

IvanKautter · ‎09-29-2010

I have confirmed a bug in ArcPad 10, which also appeared to be extant in ArcPad 7.1.1 as per my experience, in Windows Mobile 5 devices when accessing axf files. I have confirmed this bug on two separate Windows Mobile 5 devices (HP iPAQ hx2495b and Trimble GeoXM 2005).

When an existing map document is opened first in ArcPad 10, hitting the Add Layers button can result in up to a 20 minute delay in reading the contents of the default data folder when that folder contains axf files. Removal of those files results in nearly instantaneous access to the contents of the default data folder. Note that in my testing these axf files contained empty feature classes. The bug does not seem to be RAM dependent in that when ArcPad 10 is the only program running, the bug is still present.

A further complication in this bug is that when a new empty map is selected at ArcPad 10 start up, hitting the Add Layers button results in nearly instantaneous access to the default data folder whether or not axf files are present. Feature classes in the axf files are visible and able to be added to any subsequent map from the Add Layer(s) dialog. If one then opens an existing map and then hit Add Layers, again access to the default data folder is nearly instantaneous and axf file feature classes are present and able to be added.

The above behaviors are easily repeatable and as I have said extant on two separate Windows Mobile 5 devices.

On occasion, opening ArcPad 10 with a new map or an existing map will result in absolutely no access to axf files in the default data folder when hitting Add Layers, despite the fact that the Add Layer(s) dialog comes up nearly immediately. The Add Layer(s) dialog displays that the axf files are indeed there, but hitting the plus in the tree list results in a null symbol over the axf file symbol and no listing of axf feature classes.

On occasion, opening ArcPad 10 with an existing map will result in an error dialog that says axf file feature classes are not able to be loaded when opening an existing map. As above, axf files are then not accessible in the Add Layer(s) dialog.

This bug occurs regardless of whether the Check SQL engine on startup is checked in the ArcPad 10 options.

Behavior consistent with this bug has been reported in these threads:

http://forums.arcgis.com/threads/9920-Add-Layer-Excruciatingly-Slow-from-SD-Card
http://forums.arcgis.com/threads/12263-unable-to-select-.axf-files-in-arcPAD-using-GPS-unit

Removal and reinstallation of Microsoft SQL Server Compact Edition 2005 and/or ArcPad 10 does not resolve the issue.

I believe I have demonstrated that the bug is not dependent on RAM nor the number and contents of the axf files nor the mobile device which leads me to believe that the error is occurring specifically in ArcPad's manner of reading and accessing axf files.

IvanKautter · ‎10-18-2010

Sorry if this makes me seem self-important or if it in some way suggests that my technical issues with ArcPad 10 are more important than anyone else's, but if ESRI staff do check these forums, I would certainly like a response to this report that I would hope confirms that the issue exists and what is being done to resolve it.

StevenRehbaum · ‎10-18-2010

I have had several issues opening a 13 mb .axf file associated with 1 .apm in ArcPad on a Trimble Recon 400X. I thought it had to do with the complexity of the .axf (~34 feature classes all with subtypes plus ~10 domains). Every time I try to open the .apm, it just gives me the wheel of doom and never opens (killed it after an hour). I am creating an alternative .axf containing the subtype and domain values as lists (as I cannot seem to make an external .dbf work) and then referencing my new .axf to it in ArcPad Data Manager in Desktop. I am now wondering if this documented issue is somehow related to my problem. All we want to do is streamline our append workflow by using disconnected editing with our newly designed SDE database. Any thoughts? My intention is not to hijack this thread. TIA.

Steve

IvanKautter · ‎10-23-2010

Not sure if you had intended for me to respond to your inquiry but here are my thoughts.

1. If you are running the Windows Mobile 5 version of the Trimble Recon, then I'd say that your problem is directly related to what I have reported here.

2. The size and complexity of the axf file does not matter. For instance, I placed a single axf file with a single feature class in the default data folder and the same delays and errors will occur.

StevenRehbaum · ‎10-25-2010

Not sure if you had intended for me to respond to your inquiry but here are my thoughts.

1. If you are running the Windows Mobile 5 version of the Trimble Recon, then I'd say that your problem is directly related to what I have reported here.

2. The size and complexity of the axf file does not matter. For instance, I placed a single axf file with a single feature class in the default data folder and the same delays and errors will occur.

Yup. Windows 5 on it. I ran a series of tests on it. I managed to get the .axf down to a file size of 2 mb or so. It did not include any subtypes or domains whatsoever hoping I could just use external .dbfs or at the least internal lists assigned to new comboboxes. Then I began to incrimentally add more and more layers to new .axfs to see what would happen. I started at 5 with no problem. The .apm opened fine. Then I tried 10 and then 15 with no problems. 20 worked fine as well until I reached 27. It is a natural break between water types in our collection (wastewater excluded to be more specific). I received a low RAM warning from the Recon, but the .apm did open successfully and the layers were editable. It was down to around 1.9 mb. I then ran a final set including all 34 and the .apm never fully opened after a while (45+ minutes). So I am now thinking there is really something up with the .axf structure. Recommendations provided to me suggest the total number of layers going into the .axf be kept down to around 20 or so as well as decrease or eliminate subtypes, domains, export schema only, reduce the total number of fields outputted, etc...

For now, we have decided to stay with shapefiles and .apls since they are miniscule in size compared to the output .axf. We can also have them all on the Recon available for collection. I have side stepped disconnected editing by essentially creating a script that does the same thing for new data to append to our SDE production database layers (we do not make modifications or delete existing data in the field) by way of shapefile and GDB to SDE. So I have to say I am highly disappointed that we are not able to take advantage of disconnected editing after dumping quite a bit of money to upgrade our receivers and GPSCorrect. Hopefully ESRI will make some strides in regard to the .axf, but from what I saw in action at the Increase Productivity Seminar in ArcGIS 10 a couple of weeks ago, ArcPad is their red-headed stepchild and we should all use ArcGIS Mobile regardless of any tangible constraints.

IvanKautter · ‎10-28-2010

Yesterday due to performance problems with ArcPad 10 on a Windows Mobile 5 Device that meets the hardware spec, I uninstalled ArcPad 10 and reinstalled ArcPad 7.1.1 on the device. Subsequent testing on that device confirmed the same set of bugs under ArcPad 7.1.1 that I reported under ArcPad 10. Considering the claim that ESRI has made regarding performance improvements with displaying data from axf files, I find this at odds with the existence of a bug that seems to have been extant since ArcPad 7 and continues at version 10 and is directly related to the access and querying of the contents of axf files.

NickHarrison · ‎10-28-2010

I ran into this exact issue with a GeoXH 2005 Windows Mobile 5.0 and a GeoXH 2008 Windows Mobile 6.0.

I'm not very impressed.

JoelCrawford · ‎06-04-2013

Hi!

Did anyone ever learn of a fix for these bugs? I've experienced the same issues and have not been able to resolve.

With 4 AXF schema only for disconnected editing, performance will degrade as points are collected. At some point a low memory warning comes up and if you don't shut ArcPad down and reopen, then it will soon crash.

Also, just generally, right from the get-go, performance is slow collecting points. It takes a few seconds for the form to open to gather attributes, and another few seconds for it to close. This doesn't sound like a big deal, but when you're capturing 100s of points a day, it can really make for a bad user experience.

If anyone knows anything about this, has heard anything from ESRI, then please let me know.

Thanks! Joel.

WaylonLang · ‎06-14-2013

I'm experiencing the same problem with two GeoXT 2005's.