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.

Robert_LeClair · ‎04-19-2019

I understand what you're saying Ted. Realize that I'm an Instructor rather than an ArcGIS Pro developer. The only thing I can say is that the AGP Team do read the GeoNet threads and take your messages seriously. I don't know the underpinnings of why *.mdb's are not supported in AGP. Perhaps Kory Kramer‌ may be able to provide additional information.

TedKowal · ‎04-22-2019

Rober -- Forgive me, I do understand that you are an Instructor and I am not picking on you. I was just using you answers to call light on this issue.

In my discussions with ESRI the reasons they gave me was 64bit drivers and speed in geo processing. In counter arguments I pointed out that there is a WORKING 64 bit driver for access and Speed is not the issue. Any speed gained using the FGDB is lost in debugging and the agonizing futility of trying to warp the data into something useful. When said and done -- the enormous gains in speed in the geoprocessing is lost when factoring in Start to End product. I can guarantee that I can get a formatted report out to meet a deadline EXPONENTIALLY faster using an Access database than FGDB even though the geoprocessing in the FGDB may be 100 times faster.

Now to add insult to injury -- ESRI is leaving in compatibily with a Shape File which HAS NOT 64 BIT drivers. GO FIGURE!

KimOllivier · ‎05-05-2019

Use sqlite instead. It is open source, 64bit, supports spatial operations, has unlimited size, supported by all vendors, including Esri! It is much faster that access or filegeodatabases, has full SQL support and is already built into ArcGIS.

Sqlite is used in all the mobile apps because it is built into Android and Apple operating systems. There are ODBC drivers for all Databases, and it is built into Python. Have a look at the Toolbox or help and you will find it tucked away.

AZendel · ‎05-06-2019

Thanks for the suggestion. I've looked into using SQLite in the past. The big hitch is that you can't edit SQLite data in ArcGIS (ArcMap or Pro). I tried Pro 2.3.2 last week. The database that I tried to edit was a geopackage created in Pro, so I doubt there were any compatibility issues with potentially unsupported versions of SQLite. In this thread, ESRI staff more than hinted that SQLite editing support is coming. But it seems like it's been repeatedly moved down the priority list.

I tried using the open source ODBC driver for SQLite in Access (Thank you, Christian!). Overall, it worked very nicely.....until I tried to update a row with a date field in it. Or a geometry field. But there's a good chance that I didn't configure something correctly. Those are pretty small issues that I can mostly work around. Access functionality is pretty important because you can easily create reports and forms. So it'd be nice to have geodatabases natively supported in Access, but I would definitely be stoked to have SQLite access to our geo-data as well.

TedKowal · ‎05-06-2019

SQLLight does not allow for editing. To update an SQLLIGHT
DB you must overwrite the table for each update unless you want to spend additional for licensing. ESRI has not allowed SQLLIGHT to replace the personal geodatabase -- If they would that would at least be a compromise.

Additionally there are workable 64 bit drivers for Access so there is no excuse for that reason.

MattWilkie1 · ‎05-08-2019

I created a distinct idea to request SQLite as the format for future p-gdb, https://community.esri.com/ideas/16654

(To be clear, I still want to be able to read .mdb indefinitely from Esri products. I just don't think it's a good place for new things.)

ThomasColson · ‎06-20-2019

Federal Highways delivers their Road Inventory Program (RIP) results in a Personal Geodatabase. Not being able to access these in Pro means, quite simply, we will be unable to fully migrate to Pro.

JoshuaBixby · ‎06-20-2019

Thomas, as much as I like to call out Esri, and I do a fair amount, people's rub should really be with Microsoft on this one and not Esri. As Microsoft stated back in 2010, The Microsoft OLE DB Provider for Jet and the Microsoft Access ODBC driver are available in 32-bit v...:

We do not provide a 64-bit version of the Microsoft OLE DB Provider for Jet. Additionally, we do not provide a 64-bit version of the Jet ODBC driver. If you use the Microsoft OLE DB Provider for Jet or the Jet ODBC driver to connect to a data source in a 64-bit environment, you experience different problems.

Back a decade ago or so, when MS introduced the .accdb file format for Access, they really hung many companies and developers out to dry, not just Esri.

Is it technically possible to get a 64-bit application to read MDB files? Yes. Is it straightforward for an application to implement? No. The number of asterisks and footnotes that it takes to use MDB files with 64-bit applications creates risks, and I don't blame Esri for not embracing those risks, especially with an already aged file format.

I think the RIP program still disseminating data in MDB format says more about them than Esri.

MattWilkie1 · ‎06-24-2019

Thanks for this background Joshua. The textured shades of grey add depth to the conversation.

JoabelBarbieri · ‎07-18-2019

Really that this wasn't built-in from start? No GP conversion tool ? Woow!