0

We are using file geodatabases along with Micorsoft teams one drive. The beauty of this is that users all have the need files on their C drives and it is super fast. When a user edits a file it automatically gets updated on everyone elses PC. When we try going off the network it is painfully slow. So hence why we are not using Enterprise GDB along with the additional cost.

Where I am running into an issue is that if two users are trying to create points at the sametime in a feature class with the file geodatabase and then save the point it saves on their version on the C drive. However, because they both are using the same object ID which everyone makes it to the server gets posted. So if both users create a point because objectID goes in incremental order it would be objectID #7 for example. Hence the overwriting.

As I understand it you cannot have two users writing to the same feature class at the same time even if they both were using the same geodatabase.

So my question: Is it possible to change the objectID from being incremental to something else like maybe a globalID or allow us to programmatically assign the ObjectID. Can I make it so the ObjectID is not the unique identifier but something else would be. How can I work around this issue?

  • 3
    This isn't an objectid issue, it's a full-on data corruption problem. It is absolutely not safe to edit file geodatabase with multiple writers using this propagation scheme. Not only can you lose rows, you can lose everything. – Vince Jun 5 '19 at 23:49
  • If they are primarily creating new data, they could work in different databases entirely, and some one with QC and DB knowledge could use deletes, appends, or other standard ways to get the data back together periodically. Lost of work though, with some chance of messing up data, but nothing like what you are trying to do. – danak Jun 7 '19 at 15:39
2

Object IDs being the same is not actually the cause of your problem. The One Drive system is sync'ing several copied files between multiple locations. Whichever file has been written last will get sync'd to all the other locations - effectively deleting the changes made at other locations.

Even if your Object IDs were all unique across all locations, the problem would still occur. You are effectively bypassing the file/database locking mechanism, which is there for good reason!

Plain old network file shares are OK for sharing file geodatabases (ie, one copy of the fGDB on a network share). You still don't need to use enterprise geodatabases for this. But multiple copies of a file geodatabase being sync'd together, is not going to work as desired.

In fact, I would think it may have the potential to corrupt the fGDB. An fGDB is made of many files. If one persons changes update some of those files and another persons changes update other files within the fGDB, then you may get a mixed set of files that no longer work together correctly. (I don't know enough about the structure of an fGDB to know if this is would occur, but it's a principle of databases in general, that all files belong together, and sync'ing changes between PCs has the potential to sync only changed files.)

To answer your actual question:

No. You cannot change the way that ArcGIS manages Object IDs in the ways that you describe.

Even if you could it would not help with your current issue.

  • 1
    I do know enough about the low-level FGDB implementation to assert that yes, the entire geodatabase could be corrupted by race conditions. – Vince Jun 5 '19 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.