nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Retrieving a feature class which was deleted from child version.

Sandyd

Hi,

We have a Default version and a child version. One of my colleague had deleted a feature class from Child version. Is it possible to retrieve the deleted feature class to the child version.

Thanks,
Sandy.

Najděte více příspěvků označených jako

Accepted answers

All comments

AsrujitSengupta

Versions are database specific and not data specific.

In your case it might be that, the user using the Child Version doesn't have enough privileges to view that Feature Class

Sandyd

Rujit,

Thanks for the reply. I have a question..In our case the feature class was deleted from child version. Will that deleted feature class be available in default version.

Thanks,
Sandy.

JoeBorgione

We have a Default version and a child version. One of my colleague had deleted a feature class from Child version. Is it possible to retrieve the deleted feature class to the child version.

I'm confused with your terminology: Typically DEFAULT refers to a versioned database. All versions are contained within the same data base. All subsequent versions have a relationship back to default. If you choose to reconcile and post any changes made to a specific version, you do so with respect to the version from which it was spawned.

Typically, CHILD refers to a replicated database. Replication is between TWO separate databases. The relationship between a child and its parent can be one or two way. In a one way replication scenario, changes can only go one way: from either parent to child or child to parent. In a two way scenario, changes made to the parent can be syncronized to the child and/or changes to the child can be syncronized to the parent.

If you delete a version, default is secure. If you delete a child, the parent is secure. You stand to lose an changes however that were not reconciled and posted or syncronized respectively.

AsrujitSengupta

Sandy,

Just like Joe mentioned.....the terminologies that you are using are confusing.

If you are talking about SDE.Default version and a child version of the default, in a geodatabase....then NO....the data will not be present in the geodatabase.

The confusing bit is......If you are connected to the geodatabase through a CHILD version, and delete the data.....then the data gets deleted from your geodatabase, and not just from that version!! In this case you won't be able to see the data in the geodatabase even if you connect using the SDE.Default version.

If you are talking about PARENT & Child Replica, which involves two different geodatabases.....then the answer is YES ....if the data has been deleted in the Child Geodatabse...the data will still be present in the Parent Geodatabase....

Regards,
Asrujit

at_teof_4-1762577613050.png

AtheneeBallesterosTeofilo-11.jpg

JoeBorgione

Having a regular back up schedule is an essential element of any enterprise database system....

Sandyd

Okay. Which is the best backup policy for enterprise database system ? Cold, Hot or RMAN ?

JoeBorgione

Not sure what you mean by hot or cold; I have a SQL Server back end and run a back up there nightly.

AsrujitSengupta

Sandy,

I would say "Cold Backup" is the safest way to back up because it avoids the risk of copying data that may be in the process of being updated. However, a cold backup involves downtime because users cannot use the database while it is being backed up, so it basically depends on your workflow.

As you mentioned RMAN, I'm guessing that you are using Oracle DBMS. I can't really say about the RMAN much as I'm not familiar with it, as much as the other two. But as far as I understand RMAN uses the same HOT(online) & COLD(offline) backup methods.

So go for RMAN Offline Backup..;)

Regards

LeoDonahue

If you have a Parent version and Child version and a feature was deleted in the Child version, whether it is lost depends on whether it was a new feature that was added using the Child version or whether it was an existing feature in the Parent version, right? If it was an existing feature, then it should still be in the parent version, and when you reconcile/post, can't you manually review that edit and favor the Parent version?

As for backups, we have a nightly backup in SQL Server. But that means I'm willing to lose a day's worth of edits.

We set default to protected and make our child versions public. But that also means that we have to pay attention to what we are reconciling and posting to default.

If you have already reconciled and posted the deleted feature in the child version to the parent version (sde.default), you're done, it's gone. Unless you haven't synchronized changes in your replica, then that feature would still be in your replicated geodatabase (hopefully).

AsrujitSengupta

Leo,

In this thread we were talking about a "Feature Class" and not a feature. The concept would be completely different for the two.

Yes, while Reconcile/Post we can manually look at the conflicts and decide in favor of the Parent version, but for that to happen the feature should have been modified in both the versions....or else it will simply overwrite depending on what you chose(edits in favor of Child\Parent).

As for the other question, YES...it will remain in the replica geodatabase untill you synchronize.

Regards,

LeoDonahue

Sorry about that, my mistake in not noticing the feature vs feature class original post. I got the impression from Joe that we were talking about features, I misread that.

This post is confusing. Connecting to child vesion doesn't really mattter if that user owns the data and deletes something. Why bother versioning if editors are owning data?

I thought the idea was to have a "data owner" separate from the "data editors".

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.