topic Re: Approach for Data Model Changes in Geodatabase Questions

Approach for Data Model Changes

ApurvDanke — Tue, 22 May 2018 11:24:51 GMT

Hi All,

I just wanted to start a discussion about data model changes. We have many instances where we need to do some or all of the following -

1. Field addition/deletion/renaming or any other field change.

2. Domain creation/modification.

3. New Feature class/Table creation.

4. New relationship class creation.

5. Enable Z-Aware or M-Aware on existing Feature Classes.

6. Unregister replica and create new replica.

7. Add/modify subtype to existing Feature Class.

8. Assign or modify privileges on feature datasets.

In our case we have a database where we have datasets registered as versioned, with archiving and editor tracking enabled.

We usually follow the process mentioned below to do any kind of data model change.

1. Disable editor tracking.

2. Disable archiving.

3. Unregister as versioned.

4. Do the data model changes.

5. Register as versioned.

6. Enable archiving.

7. Enable editor tracking.

My query is which of the data model changes require us to disable all 3 options i.e. editor tracking, archiving and versioning and which do not?

If some data model changes do not require all the options to be disabled then what is the best practice which should be followed in each instance?

Regards,

Apurv

Re: Approach for Data Model Changes

KevinDunlop — Tue, 22 May 2018 12:53:58 GMT

I am doing this from memory so hopefully I get it all right. The biggest problem is that you must clear locks prior to most of these changes (ie disconnect users).

1. Field addition/deletion/renaming or any other field change.

-Does not require disabling stuff.

2. Domain creation/modification.

-Does not require disabling stuff

3. New Feature class/Table creation.

-Does not require disabling stuff.

-If added inside a dataset, you will need to enable it again (old stuff remains unaffected) depending on your GDB version. Otherwise, the new item won't have versioning/archiving set.

4. New relationship class creation.

-Does not require disabling stuff

-Changing item may requires disabling versioning and archiving

-Adding topologies requires disabling versioning and archiving.

5. Enable Z-Aware or M-Aware on existing Feature Classes.

-I don't think you can once it is created.

6. Unregister replica and create new replica.

-Requires versioning to be enabled.

7. Add/modify subtype to existing Feature Class.

-Does not require disabling stuff.

8. Assign or modify privileges on feature datasets.

-Does not require disabling stuff.

Re: Approach for Data Model Changes

ApurvDanke — Thu, 31 May 2018 08:37:17 GMT

Hi Kevin,

Thanks for your reply. There is a lot of shortage of ESRI documentation in this particular area i.e. data model changes as to what are the standard/best practices to be used when working in a versioned geodatabase. I have a few queries.

1. You mentioned that new feature class creation inside a versioned dataset does not require versioning to be disabled. Normally, whenever a dataset is registered as versioned, when we right click on it, we only have 1 option available i.e. to "unregister as versioned". "Register as versioned" option is greyed out. Now if we directly create a new feature class in this dataset, what options will we have enabled? Will both the options be enabled?

2. Similar to the question above, how does adding a new feature class directly in a dataset which has archiving enabled, affect the options "Enable Archiving" and "Disable Archiving" for the dataset?

3. If we're modifying an existing versioned feature class such as adding a new field or modifying existing field - if we directly do the changes without unregistering as versioned; do the changes reflect properly in any versions which still exist? Do any versions need to be deleted before doing this activity; such as posting all the edits to SDE.DEFAULT?

4. If we add or modify fields on a feature class with archiving enabled; how does this affect the corresponding H table? Will the field get added to H table as well?

Thanks and Regards,

Apurv

Re: Approach for Data Model Changes

KevinDunlop — Thu, 31 May 2018 15:20:36 GMT

1. You will only have the option to Register as Version if Archiving is turned on. If not, then you will have both options. You can't unregister even though the other features classes are already register as version since archiving was turn on. I have attach a screen shot of what it looks like after you create a new feature class in a previously registered dataset with Archiving and editor tracking turn on.

2. See image and answer above. Remember to register as versioned before enabling archiving.

3. All field changes affect all versions. Remove a field, and it removed from all versions. Add a new field, and all versions have it with null value for that field. No versions need to be delete to change the field. User locks on the database will prevent you from making a field change.

4. Yes H tables have the same schema as the normal table (plus the additional fields need for archiving to work).

Hope that helps.

Re: Approach for Data Model Changes

ApurvDanke — Fri, 01 Jun 2018 09:17:06 GMT

Thanks a lot Kevin for your detailed answers. I will try these options and see what happens.

Regards,

Apurv

Re: Approach for Data Model Changes

ApurvDanke — Wed, 21 Nov 2018 22:27:26 GMT

Hello Kevin,

These suggestions have worked for us and we no longer need to disable versioning, archiving and editor tracking for most of the data model changes.

However one question I still have is that if any fields get added or modified in a feature class, which participates in a replica, then does the replica need to be dropped and recreated?

Presently whenever we need to create a new featureclass, and it should be part of replica, we need to drop and recreate the replica. Similarly do field addition/modification/removal or even subtype/domain changes in a featureclass affects the replica?

Regards,

Apurv

Re: Approach for Data Model Changes

Asrujit_SenGupta — Sun, 25 Nov 2018 10:05:26 GMT

No. For schema changes, you don't need to recreate Replicas.

How To: Update schema changes with replication

Working with schema changes—ArcGIS Help | ArcGIS Desktop

Check the second link for supported Schema Changes..