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

[AZendel]

Thanks for responding. I was talking about SQLite, not SQL Server. Had luck with an ODBC driver for SQLite?

[KyleGonterwitz]

I do not think access is a good, stable database platform for enterprise GIS Data, but I upvoted this because it is so and convenient just to export data into to a personal geodatabase then open the mdb file in access to do crosstab queries and process data into reports, excel for charts or back into the GIS for visualization.  Yes there are workarounds and other ways to do that data processing, but there are times when I want to use Access and Excel because that is so easy anyone can do it.  

I already use SQL server, Oracle, Postgresql - I want this personal geodatabase option because I don't want the hassle of code and odbc drivers and a dsn just to get the data linkedin into access when all Esri has to do is support the create, export to and import fc from personal geodatabase in pro, or all I have to do is open ArcMap or FME and create a personal geodatabase.  I suppose I can just convert data to CSV then import that to Access, but there were things people could do with personal geodatabases... and linked tables, and application access databases, potentially Esri unsupported things... those were good times ten years ago.    

[WayneRennick]

Well said.

Customers First!

[KhaledAli1]

We have numerous MS-Access MDB and ACCDB files as well as Personal Geodatabases that we need to access. Users are having to convert them in ArcMap/ArcCatalog which is preventing them from using ArcGIS Pro without depending on ArcMap/ArcCatalog. The Interop extension is not feasible due to the additional cost. I strongly recommend that ESRI makes these accessible and supported by ArcGIS Pro as soon as possible. It is understandable why ESRI may not want to support personal geodatabases any longer but at least they should allow ArcGIS Pro Users to read and export tables/feature classes from a personal geodatabase and MS-Access databases I hope ESRI will listen to their customer needs and take rapid action. Thanks.

[BrianE1]

Esri, is this going to get implemented or not? Clearly it is something your customers desire.

[AlexBrasch]

Is Esri going to provide further comment on this? My organization also uses personal geodatabases to go between Esri and Alteryx. Alteryx only recently was able to provide some support to writing to file geodatabase (because Esri had Fgdb on lockdown for so long), but it's not quite there yet, so we use Pgdb as a go-between. We've been trying to use Pro more, but just realized we cannot access the Pgdbs, so will be stuck in Catalog. I strongly recommend that Esri makes Pgdbs accessible and supported by ArcGIS Pro as soon as possible. How has a better solution not been offered/supplied in over 2 years since this idea was created? I hope ESRI will listen to their customer needs. Thanks.

[Robert_LeClair]

Alex - as I work in Esri Training Services, I have zero sway in if/how/when *.mdb will or will not be supported in AGP - that's above my pay grade as it were.  Esri staff does read/review/answer the GeoNet threads daily and attempt to find answers.  With regard to the File Geodatabase API, this has been available for quite some time to the public. Initially announced December 13, 2010, one can download the latest API here.  For the time being, the workflow you mentioned of using ArcCatalog to use *.mdb's and converting to *.gdbs (to work in AGP) is the recommended approach.  You may want to create a model in Modelbuilder to optimize the workflow.  Hope this helps.

[TedKowal]

The File Geodatabase API is very weak and buggy.  It no way approaches an semblance of a substitute -- not even in the interim.  Because there is no ODBC driver for a FGDB any api has very limited and narrow focus use.  the FGDB does not even come close in employing standard sql....  The main reason folks uses the .mdb is because of its ability to manage, query and analysis data and still be compatible with 90% of all other software in use.  These folks have chosen Flexibility over Speed.   99.9% of my work deals with managing data - not geometries.  I only use geometry to perform queries that are impossible within a database.... my final products generally are not maps but data reports, embedments with Word, Excel -- data transfers to Financial systems .....  most of the folks voting for this will gladly give up speed for data compatibility.     What attracted me to ESRI in the first place was its ability to take and use data from any source.... now it's slowly being restricted.  

I have been slowly looking at and seriously started making attempts using QGIS for the future... I actually got it working  (somewhat) with my PGDB's.  

[JenniferBaughman1]

This really seems to be the sticking point that ESRI is not taking into account: that there are workflows, there are business needs, that require working on spatial data in non-spatial contexts, and PGDBs are a standard, efficient way of managing and transferring that data.

[Anonymous User]

I agree. I use PGDB's for querying data to summarize it and managing joins. Doing this within the arcgis environment is clunky at best.