Enable ArcGIS Pro to access ESRI Personal Geodatabases

[DavidWheelock]

Please enable ArcGIS Pro to use the ESRI Personal Geodatabase.  PGD's are compact, efficient, and an ESRI standard.  PGD's offer easy, built-in interoperability, and table data in a PGD can be easily accessed from any MS Office program or any other program able to read a MS Access database.  It does all of this in a single, compact file, without the overhead of an enterprise or workgroup geodatabase which require a database server and without the clutter of a file geodatabase.  FYI, we do have an enterprise geodatabase for when we need that.

It's deeply troubling that ESRI has chosen to deny its loyal, long-time customers the ability even to read their data in an ESRI standard format, the Personal Geodatabase.

No, a File Geodatabase is not a suitable alternative or replacement.  A FGD is a silo and cuts the data off from most other programs.  It isolates the data and can only be accessed from ESRI programs or GIS programs that have access to it and cannot be read at all by office productivity software or any other database software.  It's not useful to me.

ESRI's explanation in the ArcGIS Pro docs:

http://pro.arcgis.com/en/pro-app/tool-reference/tool-errors-and-warnings/001001-010000/tool-errors-a...

ESRI states that "Personal geodatabases do not scale well in the 64-bit environment" and will not be supported.  It recommends a FGD. 

My response to ESRI:

Please let me and your other users be the judge of whether a personal geodatabase suits our needs.  We can decide for ourselves when we need to scale to a more robust GDB format.  Permanently terminating our ability to use the PGD is not a useful solution for me.  Again, a FGD is not a suitable replacement for the reasons cited above.

[DavidWheelock]

See this closing comment with explanation: https://community.esri.com/t5/arcgis-pro-ideas/enable-arcgis-pro-to-access-esri-personal/idc-p/1179153#M19746

[DuncanHornby]

Agree 100% with this idea, I use pGDB all the time for storing analyses which I can then very easily get out into other applications, usually through an ODBC link. The irony is that forcing us to use fGDB requires us to export out to dBase format which is how many decades old???

[DavidWheelock]

Thanks, Duncan.  It's actually shapefiles that use DBase 4 format.  That's older than fGDB and pGDB!  As far as I can tell, fGDB is completely proprietary to ESRI, though I think ESRI has published the spec, as they did with the shapefile, so that it can become a common medium of transfer.

[KellyAlfaro_Haugen]

In addition you can no longer import dBase files into Access (2013 or newer) so the only way I can easily talk between my GIS tables and Access, without a ton of reformatting, is to store it as an pGDB (.mdb) and then import into Access or save it to an older version. There is so much communication I do between tabular data (coming and going from access/excel users) and my GIS files. That will be lost if they cut pGDB. FYI excel and txt does not cut it.

[MattWilkie3]

Esri has published an API for the file-geodatabase but not a specification. There are significant aspects of the f-gdb format that are not exposed in the API, and thus not available to any would-be 3rd party applications/developers.

[JenniferBaughman1]

Further, FGDBs only support a restricted subset of the SQL language, and some parts of the subset are only accessible through ArcObjects (using their PostFixClause attribute). You can't, for example, use ORDER BY or DISTINCT to select by attribute with an FGDB, but you can with a PGDB. PGDBs aren't perfect, but they do have their uses.

[VinceAngelo]

Shapefiles are actually based on dBase III+, not IV, though ArcGIS doesn't use a strict interpretation, since 255 fields are permitted, even though the specification limits dBase III to 100 fields.  "dBase III+-ish" might be a better name for it.

My understanding is that the problem with Microsoft Access-based Personal GDB support is the limited functionality provided by 64-bit Access libraries (Pro is a 64-bit app, so 64-bit libraries are needed). "Do not scale well" doesn't mean "It's a bit slow" or "It's kinda slow"; it's closer to "It's so slow, my grandchildren will need to see if the build verification script ever finished." 

If Esri were able to get an improved 64-bit Access library which was "only" four times slower than 32-bit access on the same host, and then added it to Pro, would you thank them for giving you a chance to evaluate it, or file bug reports about the performance?

- V

[MattWilkie3]

If the docs were clear about what to expect from the driver and what upstream limits drives the limits here then no, I wouldn't file performance bug reports. Thanks for telling us some of what is involved.

I think this strays from the meat of the issue though, which courtesy of @Duncan is "I use pGDB all the time for storing analyses which I can then very easily get out into other applications, usually through an ODBC link.". The real desire is to use Esri-ignorant tools to get at and manipulate portions of the content in a geodatabase that isn't possible or is inefficient using the Esri tool kit and APIs. Requests for continued Mdb and Access functionality are one expression of that central aim.

[PeterRussell]

Anyone who has any non-gis enterpise databases that have some sort of relationship to the GIS data will almost certainly be using personal geodabases. Yes you may use file geodabases to do the gis manipulation - it is a lot quicker -  but you then move the data to a personal geodatabase, fire up MS Access do all the cool things in there and then move it back to the file geodabase if needed. I have a fair number of pythons scripts that do things like this. One in particular copies data from a SDE geodatabase into a pgdb then runs a MS Access macro that uses just under 80 queries to modify the data by joining to a number of corporate databases before moving to a file geodatabase. To me, this is the sort of workflows and functionality we lose with no personal geodatabase support.

[ChaimSchwartz3]

Just wondering, since we're considering similar stuff, why you won't connect directly from Access to your enterprise (Oracle?SQL Server?) via ODBC and run your queries, and thereby skip the pGDB step?

[RickMorrill]

David and the other commentators are right on mark with the issues presented by a loss of the ability to connect between Arc and MS Access in the current version of ArcGIS Pro.  ESRI should be willing and able to support the many users of Personal GDB's if they want us to migrate to Pro.