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.

George_Thompson · ‎11-01-2018

Did you enable the run the Workgroup installer? If so, did you select the "Enable geodatabase storage on SQL Server Express"?

BrianBulla · ‎11-02-2018

Hi,

No. Basically I already had ArcMap and ArcPro on my desktop. Then I heard that using SQL Express might work as an alternative for the PGDB, so I installed SQL Express from the Microsoft website.

Now I want to use ArcMap (or ideally ArcPro) to create a Geodatabase on SQL Express. What is the screenshot you posted above from??

George_Thompson · ‎11-02-2018

Go to My Esri and look in the Downloads section for ArcGIS Enterprise (Windows)

Then download the following file:

Run that installer and ONLY select the "Enable geodatabase storage on SQL Server Express" option during the process. This will enable your SQL Express instance to have geodatabases. Set up a database server—Help | ArcGIS Desktop

Once that is completed connect from ArcMap and you should see the instance there and be good to go.

Add a database server to ArcMap—Help | ArcGIS Desktop

This implementation if SQL Express is only supported in ArcGIS via OS Authentication.

BrianBulla · ‎11-02-2018

Hi George,

Thanks for that, but I am still having issues. The main issue is that I am just an 'end user' so I do not have access to Organizational downloads through My Esri.

Also, from what I read, it looks like I would still need an authorization file in order to get things to work.

Is there a way, for just a regular end-user, to use SQL Express to create/manage their own geodatabases??

George_Thompson · ‎11-02-2018

You are correct that you will need an authorization file (i.e. keycodes) from ArcGIS Server install.

As far as I know there is no way for the "end-user" to create a SQL Express DB. This part of installation and configuration is an administrator task. Once the GDB in SQL Express is created, you can be assigned admin permissions on the SQL instance and then do everything you need.

If you need more help, I would recommend another new thread for more questions. Thanks!

ErikLash1 · ‎11-08-2018

Pro is a no-go for my users until pGDBs are supported. Let me explain.

We run Enterprise GDBs for Enterprise workflows. We have complex workflows at the organizational level that join disparate sources of data and run business units. For that we use and Enterprise Data basing solution.

However the majority of our users have no need whatsoever for the level of complexity inherent in enterprise databasing. They want to fire up the software, do some editing, get a result. Wham Bam done. And for that they use pGDBs because pGDBs are accessible to SQL, outside of ArcGIS. Again, wham, bam, done, reports printed, data delivered, actionable derivatives defined.

ESRI fGDBs are almost entirely useless as a "data" storage back end. They can't be accessed by anything other than ArcGIS. Sure, those of us in the know use QGIS to perform standard SQL queries on fGDBs, but how many basic desktop users are going to do that? The answer in my organization is none. fGDBs are one way storage containers. Data goes in but you can't get it back out. It's trapped there. And we still have no answer from ESRI as to why they won't open the spec. And so my users complain that it doesn't meet their needs and me, for my part, provide them with what they do need, pGDBS.

For the desktop user pGDBs are ideal. They are hassle free. They report in formats that desktop users want. They are relational and quickly interface with data in multitudes of other formats. Forms for data entry are easy to set up and quick to deploy. And SQL queries, while somewhat limited by the container design, are flexible enough to output all the tables that any user needs. Plus, using pGDBs doesn't require that your end user be an IT expert. Anyone that uses MS Office can use a pGDBs

Yes pGDBs are 'slow' in I/O. But they are extremely fast to the finish line for data users who have desktop needs.

Basic users don't care about I/O, all they care about is how much of a PITA it is to get a report or analysis. So for every day uses we set up our user ecosystem with pGDBs. For departmental workflows that have multiple users we set up Enterprise GDBS. File GDBs don't have a place in our workflows except for scratch workspaces.

ESRI could change that paradigm by releasing the full spec on the fGDB and a non-map interface where we can implement the SQL and data analysis workflows that are higher level than map making and what the users want. But they have not. So all we have is QGIS if we want to use fGDB data.

Our users will continue to use pGDBs until Microsoft ends MS Access. Pro doesn't work with pGDBS, Pro doesn't work for our basic users. The enhancement is necessary in the Pro product before we transition. If it isn't there, we don't transition to Pro. The calculus is really that simple.

MattWilkie3 · ‎11-08-2018

Excellent description Erik. Thank you.

My wish for Esri: recognize that you are masters in the GIS domain, and you have nothing to fear and a lot to gain to by increasing the number of inter-operable and exchange surfaces with other knowledge domains. The recent improved integration with AutoCAD is a step in the right direction. Let's do this with other areas too: not just personal geodabases but any standard database, round trip GPX files, read and write LAZ files natively, .. the list is long and your customers will thank you for it. (Instead of always wondering if the next X is something that makes breaking the Esri confinement worthwhile.)

-- Says the guy who has just spent well over 20 hours trying and failing to build a simple read only view of a non-gdb database table in ArcGIS that can be accomplished in few minutes with any SQL workbench tool.

JoePlattner · ‎11-30-2018

Just stumbled on this issue when trying to get a script to run as a scheduled task on one of our servers. It's true data in file geodatabases are almost impossible to access from non-ESRI apps.

DavidWheelock · ‎12-03-2018

Thanks Joe.

MarhensaAditya_Hadi · ‎12-18-2018

come on, file based pGDB is more convinient than folder based.

vote up!