I am using C#, ArcGIS Server 10, MS-SQL Server 2008, and I want to replace an ArcGIS SDE feature class inside of a transaction. After the deletion of the feature class, I have to create a new one with the same name (as a copy of another feature class).

After some research I have implemented the following:

    public void deleteFeatureClassInTransactionTest(string featureClassName) {
        using (WebObject webObj = new WebObject())
            // Connect to server
            AGSServerConnection agsServerConnection = ConnectServer();

            // Initialize workspace
            IWorkspace workspace = GetSdeWorkspace();
            // Initialize edit workspace
            IWorkspaceEdit workspaceEdit = (IWorkspaceEdit)workspace;
            IMultiuserWorkspaceEdit muWorkspaceEdit = (IMultiuserWorkspaceEdit)workspace;
            // Initialize feature workspace
            IFeatureWorkspace featureWorkspace = (IFeatureWorkspace)workspace;
            // Open feature class
            IFeatureClass featureClass = featureWorkspace.OpenFeatureClass(featureClassName);

            // Start transaction
                // Delete feature class
                ESRI.ArcGIS.Geodatabase.IDataset pdataset;
                pdataset = (ESRI.ArcGIS.Geodatabase.IDataset)featureClass;

                // ... CREATE THE NEW FEATURE CLASS ...
                // Simulate exception
                throw new Exception("DEBUG");

                // Commit
            catch (System.Exception ex)
                // Rollback
                throw ex;
            finally ..

However, the rollback does not work. The table gets deleted immediately.

How can I make this whole process atomic?

  • I didn't think any major DBMS would let you DROP TABLE within a transaction, then roll it back. Am I mistaken? – Kirk Kuykendall Apr 26 '11 at 21:03
  • You might try using geodatabase replication to accomplish this though. – Kirk Kuykendall Apr 26 '11 at 21:50

DDL statements are never part of a transaction, not on MS SQL Server. The same goes for Oracle.

There are however databases, like PostgreSQL, which allow transactional DDL to certain extent.

Anyway, in a geodatabase, manipulating the data model will never be "safe". Access to feature datasets, tables, feature classes etc. acquires locks which prevent modifications to the data model under user's hands.

It also seems you are misunderstanding the concept of edit sessions and edit operations: their purpose is to manage data editing, not altering the data model.

In any case, I strongly suggest that you rethink your design. Altering the data model as part of "normal" application flow is not inherently flawed (in specific scenarios), but the need to do so in a transparent way within a transaction should in my opinion almost never arise.

| improve this answer | |
  • 1
    Even if the underlying database (like PostgreSQL) supports transactional DDL, ArcObjects does not. DLL operations will either fail, or cause a commit of the transaction. – Ragi Yaser Burhum Apr 27 '11 at 0:40
  • Thank you guys. I wasn't aware of the differences between DDL and DML regarding transaction, perhaps because I have been working with PostgreSQL before starting to work on this project. I'll try to redesign the process. – Christian Apr 27 '11 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.