AnsweredAssumed Answered

geodatabase with path not using file at path

Question asked by mikedmanak on Aug 7, 2018
Latest reply on Aug 9, 2018 by mikedmanak

I'm hoping someone can explain what is going on under the hood when I create an AGSGDBGeodatabase (runtime 10.2.5) object using the geodatabaseWithPath method.


Is there any caching of the file going on?  I ask because we have run into frequent enough issues with ArcGIS Server that our apps now contain a "Reset" switch to archive runtime geodatabase and downloads a fresh copy.  In recent months (since iOS11) I've noticed some very strange behavior related to this.  When the geodatabase file is reset the current .geodatabase, .geodatabse-wal, and .geodatabse-shm files are added to a zip file and deleted.   A new version is then downloaded and copied to the same location (with the same name).  After this is completed our Map View and various list/table views are rebuilt.  


The new geodatabase is downloaded, placed in the correct locations, with the correct name, but when a new AGSGDBGeodatabase object is created using the geodatabseWithPath method it appears to be using the information from the old version of the file.  Worse yet, new data saved to an AGSGDBFeatureTable created from the AGSGDBGeodatabase is not written to the file, but appears to only exist in memory somehow.  Re-starting the app results in that cached data disappearing and the app correctly builds AGSGDBGeodatabase objects using the downloaded replacement file.  It is pretty obvious this is happening when looking at the file system in the simulator.  The .geodatabase-wal and .geodatabase-shm files are never created when the map is rebuilt, but are instantly created for other .geodatabase files as soon as AGSGDBGeodatabase and AGSGDBFeatureTable objects are created.


Is there someone at ESRI that can shed some light on what is happening behind the scenes when an AGSGDBGeodatabase object is created?  I know the stock answer is probably "you should be using v100, but this is a three year old app and this code had been working fine up until the shift to iOS 11 (and the new APFS file system).