Loading Data into a versioned dataset

406
3
12-05-2013 07:12 AM
CraigCarsley
Occasional Contributor II
Is there anything wrong with loading data into versioned feature class using the data load function in ArcCatalog?

I performed this task on a Street_Centerlines feature class in my own version, but it appears to have caused a massive data corruption to occur in both my version and the Default version.  I hadn't posted the changes, but I did perform the data load outside of an edit session.

I tested this process in an inactive sde database, and it worked flawlessly.  When I later attempted it on the active database (which has considerably more overhead), it broke.

The goal here was to delete all features from the Street_Centerlines feature class, and load in an updated version of the feature class without disconnecting users.  I know this isn't the best practice, but I was trying to work around the limitations of using Truncate and Append on a versioned data set. 

Any thoughts or insights on this topic are appreciated!
0 Kudos
3 Replies
JoeBorgione
MVP Emeritus
Is there anything wrong with loading data into versioned feature class using the data load function in ArcCatalog?

I performed this task on a Street_Centerlines feature class in my own version, but it appears to have caused a massive data corruption to occur in both my version and the Default version.  I hadn't posted the changes, but I did perform the data load outside of an edit session.

I tested this process in an inactive sde database, and it worked flawlessly.  When I later attempted it on the active database (which has considerably more overhead), it broke.

The goal here was to delete all features from the Street_Centerlines feature class, and load in an updated version of the feature class without disconnecting users.  I know this isn't the best practice, but I was trying to work around the limitations of using Truncate and Append on a versioned data set. 

Any thoughts or insights on this topic are appreciated!


So the question is why did it work in the test environment and not in the production environment.  The only thing I can think of is that with your users attached, and you deleted the features, that fouled things up.  Not much help I know, but what if you were to boot everyone off and then try it?  My experience with working with SDE is to get everyone off before doing any kind of db mantenance.
That should just about do it....
0 Kudos
CraigCarsley
Occasional Contributor II
I think that certainly could have been a factor.. who knows? The whole idea, though, was to run the data load without having to interrupt users.  My theory was that I could perform a data load exclusively on the version of the data. 

Is there any reason to believe that the data loader should not be connection-specific?
0 Kudos
VinceAngelo
Esri Esteemed Contributor
What do you think would happen if you delete all features and add new ones in a new version?

I'd expect that the number of rows in the adds table would equal the count of new rows, and
the deletes table would have the number of rows in the base table, and the base table would
be unchanged.  Other users would not have access to the version spontaneously.

Now, if the table were *unversioned*, and no users had a read lock on it, then you could slide
in new content with a truncate-and-append, no sweat.

So you really need to determine why a basemap layer is registered as versioned if you don't
intend to use versioned editing on it.  And if versioned editing is desired, then why are you
bulk-editing the table using SQL (without a safety valve like a versioned view)?  The optimistic
locking editing model is quite powerful, but it can trip you up if you don't honor the terms of
the use contract.

- V
0 Kudos