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.

RosieYacoub · ‎01-05-2018

The update query and multilevel joins that can be handled through MS Access far exceed anything ESRI has so far. If ESRI can give ArcGIS pro the same query tools MSAccess does: a UI that permits temporary joins across multiple tables and keys, allows for group by queries on any combination of attributes, allows for dependable query speed under one second for over 50,000 records--then they might be able to let go of the PGDB. Or if they provided an ODBC driver to the file geodatabase....

TedKowal · ‎01-12-2018

I am using 64 bit MS Access libraries in various other applications that require 64bit access including the buggy 64bit odbc drivers..... I have not noticed any appreciable speed changes?

TedKowal · ‎01-12-2018

The ODBC driver would have to have a "FULL" SQL implementation! The current pGDB is very limited on the SQL side.

BrianBulla · ‎01-30-2018

I also agree that the PGDB format needs to be supported in ArcPro. We have many (ie. 1000's) of MXDs that have been created over the years that have PGDB connections in them. We find the PGDB much more user friendly than the FGDB format, especially if you want to get into the back end of the data and do some advanced querying that you cannot do through the ArcMap/Pro interface.

What are we supposed to do? Convert all of our 1000's of PGDB files into the FGDB format?? That is not practical.

TedKowal · ‎01-30-2018

I am running access 2013 and I have no problems importing dbase files? BTW why do a double import .accdb holds old .mdb tables very well as links? The whole point about using a personal geodabase is that .mdb file is compatible with a countless other applications and process without having to do any additional work. The newer access versions link very well to older dbase files, sql server, oracle, post gis and countless other types of databases. Not to mention directly compatible with countless other programs. The esri file database is ONLY compatible with ESRI products. The power and mystery that brought me to ESRI was its compatibility with DATA. I also have been working with the ESRI 64bit drivers for access and have found them OK and work reasonable with reasonable speed unlike vangelo-esristaff seems to infer. Additionally, the reason for Access is not for speed, but for compatibility and the lessing of the work effort to reach the end result. So even with slower speeds, I reach my end point much quicker with fewer mistakes due to many black boxes resident in the ESRI formats.

VinceAngelo · ‎01-30-2018

I did not do the testing, but I was told about it, back when initial 64-bit Server testing was performed (during 10.0 development), by someone who had a cause to know.

If you haven't tested with ten million rows in point, line, and polygon tables, with vertex densities from 100 to 50k per feature, side by side with 32-bit arcpy, with both local and networked data sources, then we really don't have a basis for evaluation of whether the modern drivers are a significant improvement.

I have an ArcPy script I developed for benchmarking the break-even point for querying rows using a where_clause vice testing row contents in a DA SearchCursor, using a series of logrithmically increasing table sizes, from 1K to 10m rows, with thin, medium, and wide column data, and varying volumes of data returned, which I will blog about when I have an opportunity (next week, sometime). If you'd like to use the data to populate 64-bit personal geodatabases, then we'd have a way to know whether the speed is reasonable, and how much slower "slower" is. Compiling the data and script took 8-12 hours, but porting the data from FGDB to PostgreSQL took 5 minutes of effort, and tweaking the script to accept a different input folder took another five (IIRC, benchmark runtime against FGDB was 8-12 hours, but only half that for PG). I'll publish the scripts and the results with my blog entry.

- V

TedKowal · ‎01-31-2018

This discussion is not about speed but of compatibility with products which use the gis data outside of ESRI. Even though, slower, in the end due to the work effort - you reach your destination much faster. No I do not have data sets that large (as you indicated) that I use day to day, however I have worked with sets from the state in the neighborhood 4 Million records. Yes the MS database is slow even the 64 bit drivers, however the start to finish of transferring the data outside of ESRI to other products did not appreciable change. The work effort in translating the data from the file database to a compatible one far far far far exceeded the slowness of Access. In addition using MS Access did not introduce other unforeseen errors -- with access no additional programming was necessary to accomplish end goals.

Remember the story about the Hare and Tortoise!

DavidWheelock · ‎02-07-2018

Great use case Ted. I like your evidence showing cases PGDB performance exceeds FGDB in the final analysis!

DavidWheelock · ‎02-08-2018

Well put.

DavidWheelock · ‎02-12-2018

Thanks for the input Jennifer.