11

Since it is not a good idea to use ObjectIDs as primary keys in relationships, some other column will need to be used. Is it possible to use DBMS sequences to populate primary key columns in versioned featureclasses, or will I need to write arcobjects code to do this?

I've heard Global IDs can be used, but non-GIS DBA's maintaining related tables often frown at this idea.

Improve this question
3
  • Moving my answer to a comment since my memory is poor and it might not have worked properly: A number of years ago, I tried using an insert trigger on the adds table. If I recall correctly, that did work. I eventually(and quickly) went to an ArcObjects solution (that called a stored procedure), because it was easier (for me) because I didn't have to write a new trigger when adding/versioning a new featureclass.
    – Jay Cummins
    Commented Jan 27, 2011 at 20:51
  • 2
    I think it was an AFTER INSERT trigger (oracle) with a null check, so the new row would get the existing primary key value if it was moved. If it was null, it would populate. Maybe I'm wrong and it wasn't working right and I didn't realize it. What database are using?
    – Jay Cummins
    Commented Jan 27, 2011 at 20:52
  • @Jay Thanks for elaborating. My main reason for asking this question is to determine if there are other approaches to this problem besides the arcobjects code I've written to do this. I don't want to tell someone that my solution is the only possible solution without thoroughly investigating. And if so, how difficult it is to maintain it. I only occasionally write stored procedures, and most of that is on sql server. I suspect there is a way to do this at the dbms level (instead of arcobjects) but have never looked at it closely across all dbms's.
    – Kirk Kuykendall
    Commented Jan 27, 2011 at 21:47

1 Answer 1

Reset to default
7

Yes, it is possible - with a few caveats.

You can do it with triggers - but the implementation will be DBMS-specific (since you will have to implement a different AFTER INSERT trigger using the underlying database (specific) mechanism.

You will not be able to specify a UNIQUE constraint of any kind on that field since the Inserts And Base Tables can potentially have duplicate entries for every row that you modify (That is how updates are modeled in versioned databases). If you make the mistake of doing this on the base table, you will eventually realize this when your compress operations start to fail...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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