We wish to link an ESRI geodatabase to a ‘.mdb’ database. The ‘mdb’ database is updated daily. We would like to make sure that the GDB is up to date whenever updates are made to the ‘.mdb’.

1799
9
09-11-2017 11:00 PM
edwardkeys1
New Contributor

The database is created from ‘Acquire’, and is exported in ‘.mdb’ format.

 

We wish to use this ‘.gbd’ as a template for ARCMap workspaces, where all the geoscientists have access to up-to-date information. Currently many geoscientists in the organization have out-of-date files they are using on their personal machines. Currently people work from their own workspaces (.mxd), where it is never known if they have access to all the pertinent files, or if the files they have in their workspaces are up-to-date.

 

We wish to have the changing ‘.mdb’ database regularly ‘merged’ into the gdb. Additionally, other files (raster images, tenement polygons ect) are desired to be automatically updated into the ‘.gdb’ as changes occur to the master files.

 

As long at the raster image names, along with tenement polygon shapefile/layer names remain static, I think this should not be a problem (?).

 

I have been tasked with this job, however I am unaware as how to schedule updates into a geodatabase from an access database (that is updated from another individual daily). Also, I am unsure as how to update other files in the Geodatabase that change regularly.

 

Thanks kindly for any help you have, or resources to steer my attention towards.

 

With kind regards,

Ed

0 Kudos
9 Replies
JoeBorgione
MVP Emeritus

Given your organization has multiple people examining dynamic data, you may want to consider ArcGIS Sever, especiall the Enterpise Geodatabase component.  In the enterpirise environment, users have the ability to connect to a central database; if that database is maintained on  a regular basis (updated) the users are exposed to the most up to date data available.

ArcGIS Server editions—Documentation | ArcGIS Enterprise 

Types of geodatabases—ArcGIS Help | ArcGIS Desktop 

That should just about do it....
edwardkeys1
New Contributor

Thanks kindly Joe,

I agree. We will likely be getting this.

Do you know if there is a way to directly merge an 'acquire' database with an Enterprise Geodatabase? Ideally, we would like to facilitate the direct transfer between these two databases, without having to export the 'acQuire' database first into a .mdb.

Could FME do this perhaps?

Cheers,

Ed

0 Kudos
JoeBorgione
MVP Emeritus

You might want to talk to the aQuire folks; I haveno experience with it.

That should just about do it....
KevinDunlop
Occasional Contributor III

I also recommend you look into an enterprise Geodatabase.  If you try to do it in a file GDB or even a personal GDB, you will encounter lock issues at some point.

If you are unable to move to an enterprise GDB, I would recommend keeping the master GDB as read only then creating seperate GDB clones for each of your local users.  Assuming the updates are regular schedule (ie nightly), I would write a python script that updates (or replaces) your master GDB.  This script and be schedule to run automatically using Window's Task Scheduler.  After updates are complete, you can schedule another task to recreate the local clones.  The problem with this solution is that any changes to the local clones are lost each time they are recreated.  And if you have users with the clone GDB open, they won't copy correctly.  Finally, depending on how big the data is, you could be using alot of storage as each clone will be a copy. 

edwardkeys1
New Contributor

Thanks kindly Kevin.  I appreciate the detailed response. You are correct on all fronts, and will recommend purchasing ArcSDE. the ancillary question remains:

Do you know if there is a way to directly merge an 'acQuire' database with an Enterprise Geodatabase? Ideally, we would like to facilitate the direct transfer between these two databases, without having to export the 'acQuire' database first into a .mdb. Would ArcSDE make this easy peasy?

 

Could FME do this perhaps?

0 Kudos
VinceAngelo
Esri Esteemed Contributor

Cross-posted to GIS Stack Exchange (though no responses there yet)

- V

edwardkeys1
New Contributor

Thanks Vince!

Same query to you also:

Do you know if there is a way to directly merge an 'acquire' database with an Enterprise Geodatabase? Ideally, we would like to facilitate the direct transfer between these two databases, without having to export the 'acQuire' database first into a .mdb.

Could FME do this perhaps?

Cheers,

Ed

0 Kudos
DanPatterson_Retired
MVP Emeritus

none here either... just to close the loops

AndrewWhitesides
New Contributor

Hi Ed,

This is definitely a feasible task to accomplish, especially once you are setup in sde. A number of different ways to go about doing this as well depending on how complex of schema you want in your database. If this is the correct acQuire you are talking about, their documentation shows that it is all SQL Server driven. You can use Data interoperability, FME if you have access to that, or do things directly through SQL Server Management Studio of you have the know-how and if you choose to setup your Arc databases in SQL Server (this gets tricky though and is dependent on a "simple schema" in Arc/sde).

An additional way that I have found the most user friendly is to setup an ODBC connection to the database(s) supporting acQuire. Esri has some good documentation on that here. Basically this allows you to view the acQuire database tables and with a bit of work in your weapon of choice (e.g. manual copy/paste, model builder, or python), you can update an sde database. On my end, there a number of different workflows that I use to go about grabbing data from one database to bring it into our sde databases. Some of them are manual and done through reconciled and posted version workflows, others are done by myself after hours with the system offline for a bit, or even publishing a python gp script through ArcServer to do this all automatically at specified intervals.

Kind of difficult to provide a ton of detail here because of the numerous ways to do this, but I think the ODBC connection would be a good starting point.

-Andrew