View by status   

Provide an ODBC driver for the ESRI file geodatabase

Deferred

  • 1670
    Points

  • We really need access to the FGDB through ODBC.

    Especially customers using ArcLogistics are tied to the FGDB, and oftentimes the customers need an ODBC-driver for other external applications to gain access to the database.
    Tags :
     PUG, Petroleum
    Posted by   Stoffer71  to ArcGIS DesktopOther ProductsGeodatabasePetroleum Apr 28, 2010

Share this idea Report Abuse

Comments (30)


Please log in to post a comment.






rfairhur24 
Nov 20, 2014
Does a status of "Deferred" mean that Esri is declining to ever provide an ODBC driver?  There is a definite need for the ability to create interactions between file geodatabases and other databases outside of the ArcGIS environment.


 
tshindler 
Oct 22, 2014

The ability to connect to an attribute table outside of the ArcGIS environment has kept me from using File Geodatabases. Until we have that capability, they are of limited use.

I can connect to a personal gdb, using ODBC for Access Tables, to the dbf file in a shapefile, and to the SQL tables in an SDE geodatabase, so any enterprise data I use must be stored in one of these structures, in order to interact with the rest of our data.

Since ArcGIS Pro will not support personal (Access) GDBs, it will become imperative that an ODBC connector be available for File GDBs.



 
pcgv1 
Apr 24, 2014
Business Case
There is a need for a ODBC Driver or a Python Library that allows a client application to access the File Geodatabase using structured query language (SQL). Currently access to the personal geodatabase, workspace or personal SDE Geodatabase and enterprise geodatabase running on MS SQL Server, Oracle, PostGIS etc. provide this access.
 
The business case is to allow reports to be generated against these databases without the need for accessing ArcObjects. Scalable reporting applications can be written using SQL to hit business tables and data to format reports for business analytics but more importantly for data QA/QC. It is more efficient and scalable to write one python script that can hit any type of SQL driven database. The python script executes SQL which returns queries for the report.
 
The secondary, and more important case is that, by exposing the File Geodatabase to SQL the Geodatabase becomes accessible to existing and legacy systems through the common interface – SQL. There are plenty of organizations who have moved from beyond personal geodatabases for a variety of reasons – speed, scalability (size) and 64 bit support. Many organizations sharing data distribute it via File Geodatabases. But ESRI needs to recognize that there are TONS of organizations that do not have the band width to set up SDE. They don’t have servers, or DBA’s or expertise for managing even workspace SDE or enterprise SDE. Engineering companies create project GIS’s that are delivered as a file geodatabase. It is easily transferred, stable, fast and sizes for the scope of most work. And that is the extent of an organizations GIS or maybe the only GIS they have. But we can’t access it with SQL.
 
An alternative would be to make a python wrapper in the likes of pyodbc (https://code.google.com/p/pyodbc/). Support for the following object – Connections, Cursors and Rows that wrapped up a SQL syntax type feel to accessing the data. In either case, the ODBC level for what is offered by pyodbc is more than adequate for the query functionality required.


 
hotbrain 
Mar 4, 2014
I completly agree with the former posts. I miss the possibility to analyze the data with pivot functionality and do some mass updates when migrating data from other systems. Especially because the SQL functions in ArcGIS are very limited.


 
DanielMayer 
Jan 8, 2014
This is a critical need for me given ESRI is phasing out support for PGDBs (at least via 64 bit geoprocessing: see error code 001324). Currently I do all my processing in FGDBs and very often export the output to a PGBD so I can create pivots on those data in Excel.


 
alexroma 
Dec 9, 2013
I traced the first such requests to 2008. It's now the end of 2013 and ESRI seems to just ignore such a ppular request. What is it afraid of? The platform is stuffed with dozens of other little used features, but not this one. Amazing!


 
Using ArcGIS in Construction Industry. For small projects or sites a personal geodatabase is great support right now. A ODBC connection to a file geodatabse will open even more possibilities for project management. I vote for a connection to office products.
ahpgeo94


 
jrh072 
Oct 19, 2013
Connecting a (our) RDBMS to a FGDB would allow us and likely many other organizations to extend their relational database & legacy systems into a geodatabase.  In our case, we are using a complex Accesss front end & back end, the latter to be migtated to SQL soon.  Our only option thus far has been to continue to use several personal geodatabases for different geographic areas, adding many complexities and disagvanteages to having one file geodatabase.  Sounds like an ODBC connection is the answer, I'm quite surprised it has not already been implemented.


 
240robs 
Sep 4, 2013
With the removal of the MDB in the future, ESRI will need to provide a common connection to a file geodatabase. Im for a ODBC connection.


 
maphew 
May 17, 2013
I'm all for an ODBC connection to the file geodatabase, and  voted for it, however developer-hours wise I wonder if it might be better to implement the filegdb in spaital-lite / sqlite3, for which there are already numberous 3rd party means to access?


 
esonger 
Apr 24, 2013
This might not be needed if the Join functionality actually worked. Do one or the other. Fix the Join tools so they actually work, and in a reasonable amount of time, or give us functionality to connect to tables in FGDB from another database front end.


 
LarsCLarsen 
Apr 4, 2013
We have a product that really needs FGDB performance, but our users stick to mdb mainly for one reason only. That is the lack of access to the database from standard tools. So yes please, we need this as a part of the FGDB API.


 
larry.kwasny 
Oct 23, 2012
Our entire workflow which includes data entry, verification and reporting relies on a connection to MS Access by numberous work units and staff within our organization. We will not be migrating to 10.1 until an ODBC connection is provided and I find this as a step backward as far as database interoperability goes. 


 
petersm6449 
Aug 13, 2012
We almost always need tap into the attribute table from external software such as SAS or Stata.  I prefer to use file gdb as much as possible but unfortunately must use clunky old personal gdb (or even export to DBF) almost all the time because of this unbelievable limitation.  Even if the ODBC connection was read-only, this would save me a TON of hassle and extra steps.


 
powerplanner 
Jun 19, 2012
The report function in 10.1 is not any differnt. at UC 2011 wasnt it promised to have better report writer?


 
jupitergis 
Jan 9, 2012
Sure would like to be able to connect to file .gdb and query layers, tables with a simple connection string and sql statement, with PHP, ASP, html scripting etc. Maybe I should be able to already but since I'm not a full time programmer I haven't figured it out yet.


 
rmercer 
Dec 6, 2011
I would like to have all of my spatial and non-spatial data in a common file geodatabase.  i routinely need to run queries and do joins and relates on this data to create new datasets or reports.  This functionality is best done in MS Access.  Since no ODBC driver exists, any tables I want to reference in Access, have to be in a personal geodatabase format.  This means that I have to export from a primary FGDB to secondary PGDB which always creates the possibility of data loss.
Please follow through on this essential driver that you promised when 9.2 first came out!!


 
csny490 
Nov 14, 2011
This would certainly helpl facilitate better system integration. Cmon ESRI!!!!


 
curtvprice 
Nov 1, 2011
> Doesn't the ESRI OLE provider do this?
http://resources.esri.com/help/9.3/ArcGISEngine/dotnet/0ec7f577-5dbd-4a60-b1f3-d5ef4a1426e4.htm

The OLE provider is for ArcSDE data sources only -- not file GDB.


 
evtinker 
Oct 6, 2011
This was mentioned as being in the pipeline way back when 9.2 came out.  I run processes daily that require access from MS Access and so I am forced to use personal geodatabases.  The problem is the dataset is growing to the point I am running up on the 2 gig limit of Access.  A file GDB would be awesome here if I could only connect to it.  I tried setting up these processes using just ArcGIS models instead of MS Access.  Since ArcGIS does not include the ablility to join 5 tables I am stuck using MS Access.

Please give us an ODBC connection!


 
powerplanner 
Aug 3, 2011

I use crystal reports and would like to hook directly to the FGDB and thus avoid exporting to personal gdb.  Since the report functionality is so limited in ARC, I wish you would reconsider this function.



 
tharen 
Jul 29, 2011
The lack of an ODBC driver is the main reason I haven't fully adopted the file geodatabase as my storage format of choice.  There are many times when I need a direct connection to my tabular data.  If I have to worry about importing, exporting, etc. I won't use FGDB for my projects.  Every other serious RDMS provides for ODBC in some fashion.  If I could access FGDB data from third party apps directly I'd be all over it.

Thanks for the API.  It's a start, maybe it will spur on a third party ODBC driver.


 
curtvprice 
Jul 28, 2011

The API is not what this is about, most of these users have ArcGIS installed, so they can just run Copy Rows.

What we want are more sophisticated queries (union, cross-tabulations etc) with better performance than the available GP tools, which necessarily operate outside of the file geodatabase so all formats can be supported.



 
despina 
Apr 25, 2011
Hello everyone,

Currently the File Geodatabase API allows you to read and write data in the geodatabase. This would be an alternative to needing an ODBC driver.http://blogs.esri.com/Dev/blogs/geodatabase/archive/2010/12/13/File-Geodatabase-API-details.aspx

Regards,
Despina M.


 
cokinos 
Feb 19, 2011
At then end of the data the File Geodatabase (.gdb) should be able to be read by other DBase programs (MS Access, MySQL, etc).

I will continue to use the Personal Geodatabase (.mdb) until ESRI stops supporting it or gives us the ODBC driver for the File Geodatabase.

It really is that simple.


 
njennings 
Jan 6, 2011
I agree with some of the user comments.  I think what mostly is needed from ArcLogistics is the resulting data from the routing scenarios so we can use it with other systems.  I did manage to build a Python script that puts together data I need that is/will be used with a customer billing system that includes route numbers and service locations (separate from physical billing address).  I think if it was possible to either directly tap into this and/or use SDE (in my case SDE, since our billing system is in Oracle), this would satisfy a number of needs on non-gis database sides.

I did post and vote on the SDE Idea page related to ArcLogistics as well.


 
jfrigle0 
Nov 17, 2010
I see what you did there.

This is WAY overdue, especially considering all hoopla pushing the FGDB. Stop the hand-holding excuses already.

"Sometimes Access just provides much better ways to analyse the data." Give us an ODBC connection to access tables inside FGDBs so we can access our data with tools that don't suck.


 
giu 
Aug 18, 2010
that would be great. sometime I have to export my gis file geodb to pgdb and then use in access. I do this so I can connect  to land / road / asset / work order databases. it would be much easier if you didnt have to have the extra step of converting out to another format and you could have a live link to a file geodb via ODBC

Sometimes Access just provides much better ways to analyse the data.


 
jwickstrom 
May 17, 2010
Hello,

Can you tell us more about what you would like to accomplish?

The reason I ask is that we would like to meet these objectives through import and export to a standard format (not file gdb).

Even if ArcLogistics were in a format easy to read/write (i.e. mdb) we would not want you to do so directly.  It is an internal and "unfriendly" format since we store things in BLOB fields and whatnot.  Writing to it would be highly error prone in that you would likely break some presumption the application is making or other integrity.

Thanks for the suggestion and I look forward to hearing more about it.

Jeff




 

 

Terms and Conditions   |    Feedback   |   FAQs
Previous MonthNext Month
SunMonTueWedThuFriSat