We are currently working on a complete redesign of our geodatastores. I have to say that their evolution took more than 20 years till now. We identified the following key features in geospatial data management:
permissions to read or write portions of data
hot update while running services that rely on data (Transactions and ACID ...
There are tradeoffs. I don't use this option because it limits the ability to create "check-out replicas" (show stopper for me). Another limitation when you chose this option is that you can't edit feature classes that participate in a topology.
Many people use this option because they need to support third party (non-ESRI) applications. When edits are made ...
Right-click on the Feature Class in question using ArcCatalog or Catalog window in ArcMap. View the Feature Class Properties. Under the General tab there is a Versioning section which will contain your answer. Example when option to move to base is checked:
In short, unsaved/temporary edits in ArcGIS geodatabase are stored in a table, specifically Delta tables also know as A (add) & D (delete) tables based on the information I'm aware of and researched.
In Esri's Registering as versioned with the option to move edits to base
If you decide to register a feature dataset, stand-alone feature class, or table ...
The answer is yes that the number of rows in the sde_state_lineages table directly impacts performance of the geodatabase. 200k rows is not considered "alot" but that is relative to your available resources and assuming there are no versioning issues that would require a diagnose/repair. Continue to compress often.
From your naming conventions it looks like ...
Versioning is for editing in a multi-user environment. Replication is for replicating your data in a multi-database environment. They are two very different things.
In a multi-user environment the versioning is used to enable handling of conflicts where two (or more) editors may have edited the same feature. It gives the abililty to choose the correct ...
ModelBuilder is old, clunky, and is not getting any significant updates with ArcGIS Pro, if this tweet is any indication. I have never been a big fan of it (though begrudgingly still use it when I have to), so you might consider this answer as a sidestepping of the question and a recommendation to look at alternatives.
FME is arguably the most obvious ...
After some further research I have confirmed that this is a known bug.
Hopefully adding this information here will save someone some time in the future as it was not easy to find using Google or the Esri site.
Submitted: Jan 8, 2013
A lineage length of 289 indicates 289 states participate in that lineage. If this is after a compress operation, this indicates there are 289 states that cannot be compressed together to collapse that lineage without affecting the versioned table structure. A likely cause of this is that there are versions that directly reference those states. You can see ...
It fails because the version creation block is inside the loop over existing version. As it is now, the code loads the list of version, reads the name of the 1st one, and if the owner is different than the one in versionName, it creates the version.
To fix it, you must move the version creation block outside of the loop. You create a flag variable ...
Postgres all the way as others have said, however if you want to keep it portable and easy to move, then you could always look at using SQLite + the Spatialite extension.
Not as easy to use as Postgres in terms of management tools, but QGis CAN talk directly to a spatialite enabled GIS Database without any problems.
I actually use SQLite + Spatialite for ...
Try disabling archiving before you delete anything. When you disable archiving, you should get a message that gives you an option to keep or discard the history (the _H table). If you keep it, then it becomes a regular ol' feature class. The _H tables track the history of changes to the default version, as you make edits to a feature class that has archiving ...
I've wrote similar python code what your trying to do. Try the following:
Check current version using Describe/Workspace properties
Create ArcSDE Connection File to connect to version you want to replicate
Replicate version using Create Replica
Hope that helps.
A quick search of the ArcGIS help site turned up a couple of items that might be of use to you.
These are all located under the ArcObjects SDK 10 for Microsoft .NET Framework.
The first item discusses Listening to Versioned Events
The next item discusses Reconciling versions
The general arguments for each of these include specifying the source version and ...
The introduction of Python toolboxes at ArcGIS 10.1 for Desktop invalidates your four year old statement that all:
Toolboxes, and thus their models, are binary.
Standard toolboxes are binary but Python toolboxes (*.pyt) are text files.
Consequently, I think Python toolboxes should be considered if version control of source code trumps the requirement ...
You can export the schema:
Copying a geodatabase schema using Extract Data Wizard in ArcMap
Alternately use the Geodatabase Designer/Diagrammer
Geodatabase type matters for the type of delete you should use. If you're using an ArcSDE geodatabase, the recommended method is to use IRow.Delete().
The ITable.deleteSearchedRows() is recommended for local (file and personal geodatabases):
See the ESRI link (under the 'Deleting Features' heading) for detail and examples:
I found what looks to be the solution to this from Thomas Brown at the old ArcGIS Discussion Forums:
Once a topology dataset is register as versioned, you must perform the
validation within ArcMap while editing.
Simply add your topology to ArcMap (as the DEFAULT version or any
other), add your topology toolbar, start editing and click the
Since you would "prefer everyone on ArcGIS, using ArcSDE, but ... don't have the budget" you may be interested in "GISquirrel" http://www.gisquirrel.com which gives multi-user editing of PostGIS tables in ArcMap (at Basic licence level). This may give you what you want for all users, but if you still need QGIS in the mix then you are quite right to consider ...
In Arcgis the dataset version is set at Workspace level. As you have mentioned in your question, you should create a connection file for that version and change the handle to the featureclass or table. something like this:
worspace = "c:/connectionFiles/version1.sde/"
layerName = "parcel"
##to change ...
You are almost there. You just need to test in the list comprehension you get that the v.name is not equal to certain strings.
"""Define parameter definitions"""
param0 = arcpy.Parameter(
Have you considered using the arcpy ChangeVersion_management() tool?
From the ESRI Help page:
"Each input feature layer or table view will have its workspace
modified to connect to the requested version."
It's pretty straightforward and doesn't require a new connection file or modify the existing connection file. You just pass the features you ...
The Protected version allows other users to create child versions and edit them, but they cannot (as you have discovered) post their edits back.
The owner of the protected parent version can post the edits back. If the child versions are set to public, then the owner (administrator) can change to those child versions and post those versions back into the ...
The best resource I've come across to provide an answer is Esri's Not registered as versioned or unregistering data as versioned
There are no ways I'm aware of redoing/undoing edits in unregistered tables. However, this resource provides further insight as to possibly finding a solution.
....As mentioned above, your data is initially not registered as ...
Manually trace what the database does:
Create a test table:
In SQL Developer,:
create table test_table
In ArcCatalog: Register the table with the Geodatabase
Register the table as versioned, with the option to move edits to base.
In SQL Developer, run this query:
Note: I need ensure that I use a connection that has ...