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

[Anonymous User]

I use FGDBs for most of my work, but still use PGDBs extensively because I design queries there all the time. ArcGIS is awful at joins (like what it does to field names), Access is wonderful to use for this task. And yes, I also use it to coordinate with other software which would be unable to access the data within a FGDB.

[MattWilkie3]

Personal Geodatabase a.k.a. Esri specific tables inside an Access MDB container is clearly a dead end road, or a cul-de-sac at the very least. There are reasons both inside and outside the Arcgis ecosystem for this. External factors include: MS has deprecated .mdb in favour of .accdb; the 2GB file size limit; mdb requires distinct SQL syntax and reserved keywords. I'll leave it to someone else to enumerate the Esri reasons. 

I submit that a fruitful path forward would be to embrace SQLite as the future Personal Geodatabase format:

• SQLite db are single files that can be moved and hosted anywhere. There's no chance of breakage because of forgetting a side car file somewhere along the way.
• ArcGIS already has baseline support for the format via Support for OGC GeoPackage specification in ArcGIS. 
• SQLite is used under the hood by ArcGIS Collector already anyway - How To: Access offline edits from Collector for ArcGIS directly from an Android or iOS device 
• The SQL Features That SQLite Does Not Implement list is mercifully short
• There are ODBC drivers which would allow clients to continue to use MS Access as a front end. In the event there are limitations of this route:
  • There is an actively maintained on all major platforms full featured client in DB Browser for SQLite (there are other clients also)
• SQLite is as about as future proofed as one can get. It has official authors' commitment through to year 2050 and is recommended by US Library of Congress for digital preservation. See Long Term Support.
• SQLite is the most rigorously tested application/library/format I've ever read up on, with 711 times as much test code and scripts as feature code. See How SQLite Is Tested.

Note: this suggestion is different from Add support for SQLite/SpatiaLite and PostGIS geodatabases  (which I encourage people to vote for and comment on). What I'm proposing here is "make SQLite-gdb a first class citizen on par with File-GDB", which is more than just "supports", which Esri can argue it does already. (For me 'no editing' means

'not supported').

[TedKowal]

I could live with that option/compromise if Esri would allow SQLite as the replacement personal geodatabase.  Right now it is a complete re-write for any feature editing or updating.... currently anything more than "Static" use is non-existent.  Both the MDB and ACCDB flavors of access perform fine with SQLite.

[HansSträngby]

I agree 100%!  We have about 300 different mdb-files that is connected to 3 different mxd-files, with a lot of Data Frames. (About 100 Data frames in each mxd-file) Each month many of the mdb-files are updated/changed via FME.

This system work perfectly well. I don't know how we can do this in a file geodatabase in an easy way?

[KeithD1]

Nice job "selling" SQLite - this sounds like an ideal implementation.

Not crossing my fingers on ESRI doing anything that might loosen their monopoly on GIS data, but we can always hope...

[BrianE1]

Agree with this as well. With so many votes up and this Idea being 2 years old, it is surprising that Esri still refuses to enable this connection. Customers first.

[AZendel]

Yeah, the ESRI approach of Add Join --> Select by Attributes --> Calculate Field can take forever, even on properly indexed fields.

[AZendel]

Wait?!? What?!? The Data Interoperability Extension allows Pro to access (pun intended) the "inaccessible" 32-bit Personal Geodatabase??? That's angering to read.

[AZendel]

I got some emails from ESRI staff that suggest SQLite support is coming to AGP. That was hopeful because I used PGDB's very frequently so I could have SQL access to my GIS data. I tried the one free SQLite ODBC driver to link tables to MS Access so I could build queries and reports. But anytime I tried to edit a row that had a date in it, Access would display an error and the row wouldn't update. What ODBC driver(s) were you using to work with SQLite data in MS Access?

[TedKowal]

i have been using the standard SQL Sever drivers... i have no major issues with dates (outside of ESRI) between SQL Server and MS Access.  Since I con only do a complete re-write from ESRI to SQL Server those dates have not caused any issues for me.

This may help you somewhat with common date issues between SQL server and MS Access