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; } } }

Traditional Versioned enterprise database editing default version - is it too late to recover a previous snapshot of a feature class?

imansbburg

One of my staff lost features in a feature class on our database, and we're not sure how. It is not everything and hard to say how certain issues were deleted. We typically edit directly to the DEFAULT version, so there's no other version to go back to prior to post / reconcile.

I've tried changing the 'moment in time' or 'history' view in the version but nothing changes. Is there a way to export a prior version of the SQL database itself? What are the best practices for running periodic backups of an enterprise database if we edit the default?

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

Geodatabase Administration

Versioning

Accepted answers

All comments

George_Thompson

If you have a full backup of the SQL database before the point in time of the deletions, then you could restore to another SQL Instance and see if you can export the features you need. I think this may be the only way that you could get them back.

The backup process is not an Esri one but more on the SQL Server side of the house. The frequency in which you do the backups depends on your organizations policies. Many people do it daily or weekly with daily differentials.

I would also recommend not just editing in DEFAULT due to issues like you have experienced. Create versions off DEFAULT for editing (https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/traditional-version-scenarios.htm), then follow the reconcile / post process: https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/recommended-version-administration-workflow.htm

imansbburg

Thanks George. Yes, I'm still waiting to hear back from IT about what backups they have available. I know they run nightly backups but not sure how far back they keep. We only have 3 staff members that connect directly to the default (the actual GIS staff)-- the few other staff that perform edits do it through an editable feature service in our Portal-- this is still a good practice, right?

The day GIS staff lost features was also one where they were getting odd behavior in ArcPro and various drawing alerts. I suppose I'll have to show them about making other versions for more intense edit sessions.

SimonAlford

Additionally, you can protect the default version from being edited by non-administrative database users.

https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/create-modify-and-delete-versions.htm#:~:text=Protect%20the%20default%20version

With the permissions set to 'protected' for the default version, any user can view the default version, but only the geodatabase administrator can edit the version directly and post edits from other versions.

Here is some information about the Geodatabase administrator in SQL Server - https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/manage-sql-server/geodatabase-administrator-sqlserver.htm

George_Thompson

Editing via feature services is supported and done by many organizations. You may want to make sure that the feature service was published from a version other than DEFAULT or you could have similar issues.

imansbburg

If I publish from a different version than the DEFAULT, do I need to incorporate any new automated scripts for reconciling/posting edits? Currently everything is off the default with a weekly compress database script. Can I just create a child version from the default and publish that way?

George_Thompson

Yes, you could create a child version and publish that. You would then need to incorporate some additional processes to what you do now. Here is some great doc / code samples that review this:

Hope this helps!

imansbburg

I looked and it appears the reconcile and post process is already incorporated into our weekly compress database script using the ListVersions and ReconcileVersions commands. If I simply create a child from the default version to republish editable services from that, would that theoretically be all I need to do for an extra safeguard?

Also I have yet to figure if using the option to 'create version for each user' in the download offline options on the service settings might alternatively take care of the versions, however does that matter if we're normally always in a connected, albeit signed in, environment? Given recent drawing alert issues for staff connecting to the database, I'm curious if editing via feature services would alleviate the issue.

Thank you for all the helpful insight so far!

George_Thompson

If I simply create a child from the default version to republish editable services from that, would that theoretically be all I need to do for an extra safeguard?

That could be one pattern, but that may cause blocking states during the reconcile / posting process in the future.

I am not sure about the second question but could help with knowing what versions are not reconciled / posted yet. The big thing is that if you want to keep the Enterprise Geodatabase clean, to reconcile / post / then delete that version. That can help prevent "blockers" later on in the compress process.

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.