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.

JasonMcNees · ‎02-19-2020

One of the best things about Personal Geodatabases for my own personal workflows, is they are an intermediate "middle man" that allows tabular data to be moved back and forth between Arc and Microsoft Access, reliably, and without corruption, or unintended reformatting of field types that "import wizards", or Microsoft Excel, sometimes impose or incorrectly guess at. (i.e. you can import a table into Access, do all the advanced manipulations/calculations/edits/etc you want on it, then create a personal GeoDB, open that Personal GeoDB in Access (not Arc), import your table into it from your .accdb, then close it, open ArcCatalog, and then import that table from the Personal GeoDB into a File GeoDB. Similarly, you can export a table in ArcCatalog from a File GeoDB to a Personal GeoDB, then open an Access .accdb, import that table from the Personal GeoDB into it, do all your manipulations you want to it in Access, then move it back to the File GeoDB the same way.

Might have made that sound harder than it is - it's really easy to move data back and forth this way between a File GeoDB and Access, where a Personal GeoDB simply serves as an intermediate container to move copies of tables back and forth between the two. This is only necessary b/c Access has way, way better user interfaces and capabilities to query, edit, customize, and re-arrange tabular data in bulk.

In my dream world, I wish Esri would develop some kind of an "Advanced Table Editor" module in ArcPro, that could do just about everything you can do in Microsoft Access inside of the ArcPro application to edit, query, and modify tables and tabular data - then the extra hassle of moving stuff back and forth between Arc and Access to do advanced editing/crunching of tabular data wouldn't be necessary. Imagine how nice it would be to open a table in "Design View" inside of an Arc application, and be able to use your mouse and keyboard to delete, rename, and re-arrange the field order of tables to your hearts delight, without having to string together a bunch of geoprocesses... Or to use a great query interface like Access has to modify, append, or create new tables that can update a whole bunch of fields at once, based on a whole bunch of conditional criteria at once, in a fraction of the time it would take to re-create the same thing using geoprocessing tools or scripting it out in Python.

DanielleKulas · ‎03-03-2020

Manipulating data in personal geodatabases is a crucial step in of our Program's data management workflows and as many have already stated here, the suggested file geodatabase workaround is not sufficient for what we need to accomplish. I hope a better solution is implemented.

MattWilkie1 · ‎03-05-2020

Feature Class to Feature Class and Feature Class to Geodatabase tools in ArcMap will do this. The same tools in Pro will not, however I wouldn't be surprised if they actually did work when fired directly from a python script. I think it's the validation routine that happens when an object is picked interactively in the tool that doesn't see or disallows p-gdb not the actual backend functions.

LonSharp · ‎03-05-2020

Neither will batch convert the files, unfortunately.

-Feature Class to Feature Class doesn't have a "batch" or "multi" option.

-And Feature Class to Geodatabase is a one-to-one or many-to-one operation. No many-to-many.

From what I read before posting that comment originally, ESRI recommends what I was talking about: Use ArcMap or Catalog to create a new FGDB, then copy/paste the contents of the PGDB to it.

Anonymous User · ‎07-27-2020

I don't want to use MS Access as a geodatabase. I just want to be able to add an Access table to a Pro session and join it to a featureclass so that I can represent data. As a local government agency employee I have many programs to administer such as housing, building, demographics, etc. My data is not static. It lives, grows, and changes for decades. There are only a few situations where I need to treat data as a stand alone - time frozen snapshot. Most of the time my job is to present the data as it exists at any given moment with minimal advance notice (as in, "how fast can you pull this up and print the current copy?"). Importing and exporting data back and forth is not viable and neither is storing copious amounts of associated data directly in ArcGis (any platform). Administering dozens of ArcGis installations with occasional users is too much overhead. Storing the data in MS Access allows for program data to be managed by many users in a familiar platform that they are likely to use for other business purposes. It is superior to Excel, which I can still join to, because it provides for better data normalization and control. I have Access databases that each include upwards of 20 query and format based reports that are regularly used. I need to also be able to represent this data geographically. ArcGIS isn't the tool for that and neither is Excel. Sure SQL is a more ideal multi-user platform for data tables but It provides its own challenges. SQL backend with MS Access front end? Maybe. Again, I work for a small agency (City of 11k population). We have most, if not all of the reporting and analysis requirements of larger agencies but no where near the staff to afford the same overhead for time or technical staff.

Robert_LeClair · ‎07-27-2020

Shawn - in the What's New in the Geodatabase at ArcGIS Pro 2.6 blog article, there's a paragraph on OLE DB and ODBC support for read-only connections. Using the Microsoft Office 12.0 Access Database Engine OLE DB Provider item, you will be able to connect to Access databases in the Catalog Pane or Catalog View and work with the tables in ArcGIS Pro. ArcGIS Pro 2.6 releases soon.

KoryKramer · ‎07-27-2020

2.6 should actually be available at some point tomorrow! For a peek at other things coming in ArcGIS Pro 2.6 from the ArcGIS Ideas site, check out Ideas in ArcGIS Pro 2.6 - YouTube

KimOllivier · ‎07-27-2020

I note that the new 2.6 OLE interface is read-only, and presumably one cannot copy fgb tables or featureclasses into Access either.

But there is a simple way using the Microsoft Access Drivers (64 bit) and the python module pyodbc. With these installed I am able to write a single page python script to translate tables between the two formats. With a bit of extra work I am able to export the shape field as WKT or WKB into the Access table and bring it back again in a lossless round trip. Not the same as joining tables inside ArcGISPro but it does provide a simple exchange.

BranislavBlagojevic · ‎07-28-2020

Kory,

Thanks for the great video review of the new in ArcGIS Pro 2.6!

Anonymous User · ‎07-28-2020

That looks promising. At least for my use.