8

I am having trouble editing a feature class that is in a feature dataset.

We have added just the single feature class as a layer in ArcMap and are using the "Start Editing" function on the Editing toolbar to edit.

ArcMap reports that "All data sources in the map are registered as versioned or you lack privileges to modify data sources which are not registered as versioned.".

The database and feature dataset are versioned. We confirmed this with ArcCatalog. We are also unable to make non-versioned edits.

We have selected to edit a version from the Editing toolbar options.

sdelayer reports that the connecting user (also the schema owner) has SELECT, INSERT, UPDATE, DELETE permissions on the layer.

Oracle's dba_tab_privs reports that we have SELECT, INSERT, UPDATE, DELETE permissions on the business table.

If I connect to the geodatabase with the SDE user, I cannot grant new privileges to the schema owner to the feature dataset. ArcCatalog reports an automation error.

If I connect to the geodatabase as the schema owner, I can grant new privileges (to "myself") to the feature dataset. However, I don't know if they have made any effect.

This is ArcGIS 9.3.1.

What is left? Are there any sure-fire solutions?

UPDATE: I copied the feature class to a new one (located outside the featuredataset), which I can edit. When I put the feature class inside the feature dataset, I can not. What has the final say on feature dataset permissions?

I need to iron out what's causing ArcMap to think "you lack privileges to modify data sources".

The feature class in question has many (hundreds) of relationship classes. I suspect that these are the source of my troubles. I will ask a separate question about those...

Improve this question
4
  • Are you able to edit using non-versioned editing?
    – Derek Swingley
    Commented Sep 14, 2010 at 18:41
  • No, that's also not working.
    – mwalker
    Commented Sep 14, 2010 at 18:43
  • Can you edit anything in your GDB?
    – Derek Swingley
    Commented Sep 14, 2010 at 19:14
  • 1
    Were privileges assigned using ESRI tools? And were they assigned at the Feature Dataset level? Neither sdelayer nor dba_tab_privs are geodatabase-aware (they don't know about feature datasets) so you might need to re-assign privileges on your feature dataset. I'm still not sure why you can't edit as the schema owner though...it might be time to contact support.
    – Derek Swingley
    Commented Sep 14, 2010 at 20:36

7 Answers 7

Reset to default
5

I believe that the issue was triggered by loading an XML geodatabase export into SDE. The original export had geodata that was owned by a user that did not exist in the database when the data was loaded. Consequently, the data became owned by the user specified in the connection (instead of the user referenced in the geodatabase) Thus:

Original SDE database had users:

  • SDE
  • USER1
  • USER2

New SDE database has users:

  • SDE
  • USER1

Our connection to the new SDE geodatabase was made with "USER1".

So when we loaded the XML dump, USER2's feature classes became property of USER1. Except the geodatabase said they belonged to USER2. This only is an issue if the features are in a feature dataset.

Improve this answer
2
  • 1
    Have you been able to sort out the matter? I am also facing a similar problem and none of the above solutions worked for me. pomi
    – user3660
    Commented Jul 14, 2011 at 21:54
  • The issue was resolved by deleting and re-importing the dataset, except creating all possible users so that ownership was restored in the feature dataset.
    – mwalker
    Commented Jul 14, 2011 at 22:30
2

When you start editing, do you get a warning/message that there are different coordinate systems in the workspace and you may experience problems? I ran into this and that error message you get is completely false. SDE wasn't the one blocking me from editing, it's ArcMap.

I had a couple of shapefiles in the map that were in a state plane coordinate system. The SDE layers were added in after the shapefiles, but the shapefiles defined the coordinate system of the workspace. Anything added after that were transformed into the shapefile coordinate system.

We thought it was SDE as well, but neither SDE nor Oracle were giving any indication of a lack of rights issue. We figured out that the coordinate system was the probelm and ArcMap didn't know how to reconcile the error, so it just blocked you from editing and blamed the database permissions.

We ended up rebuilding the MXD and added the shapefiles in last so as to avoid the coordinate system error.

Improve this answer
1
  • All the data was loaded into SDE, but this is a really good answer for folks who are hitting this situation.
    – mwalker
    Commented Oct 13, 2010 at 21:03
1

Double-check that you're connected as a user with edit privileges by using sdemon (or take a look at the process_information table in your sde schema when you're connected via ArcMap).

Improve this answer
1
  • sdemon and process_information report that I am connected to the schema owner.
    – mwalker
    Commented Sep 14, 2010 at 18:54
1

You also need to make sure that you have the Create Table Privileges as the versioned edit will add the A, D and I tables to the schema. Also what is the default schema of your database user?

This may sound silly but is your SDE connection in ArcCatalog changed to be the new version or still set to default?

Improve this answer
2
  • We configured the version to automatically post edits back to DEFAULT. The database user is the schema owner, and its own schema is the default. The database user is able to create tables in its own schema AND the SDE schema. It's just the feature dataset that is interfering (somehow...)
    – mwalker
    Commented Sep 30, 2010 at 0:02
  • give this a try - in ArcCatalog, right click on the FDS while logged in as SDE User - select privleges, in the GP Tool type the user you want to use - Grant the View and Edit Permissions - Run the Tool - Create a new Version - Create a new connection pointing to the new Child Version - Add Data To ArcMap using the new Connection File - Test Editing
    – CDBrown
    Commented Sep 30, 2010 at 1:26
1

Had an ‘Incorrect edit version type' message popup when attempting unversioned edits on feature classes within a feature dataset. The following solution may help out with those that come across the original issue (use with caution):

Register the unversioned feature dataset causing trouble as versioned and then immediately unregister as versioned. When unregistering as versioned arccatalog may notify you that there are edits that haven't been compressed - I selected the ‘compress edits to base’ option when unversioning. Now able to edit unversioned feature classes under the previously troublesome feature dataset.

Improve this answer
0

Not sure about the versioned EDITs (i didn't test it) but for the non-versioned EDITs , do this, -Go to the editor drop-down button on the editor toolbar, open the drop down, click the last menu-entry, options. -A dialog will open, on this dialog, click the Versioning tab, and then UNCLICK/UnCHECK the first checkbox "Edit a version of the database with the ability to undo and redo". -Go back to the start editing and it should work.

Improve this answer
1
  • mwalker said in his original post: "We are also unable to make non-versioned edits."
    – Derek Swingley
    Commented Sep 15, 2010 at 7:20
0

what version of arc is this? This reminds me of a problem I had in oracle where I had differeing(I knowit is not supposed to be possible) coord systems on two featureclasses in the same dataset. I think that happened on 10.2 and arc 9.2. don't remember the fix except that we had to re-load the data with the correct coord sys.

Improve this answer
1
  • It's Arc 9.3.1 SP1. I will query the DB to see if something has a different spatial reference.
    – mwalker
    Commented Sep 16, 2010 at 20:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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