Vince, the admincmdref documentation for 'sdelayer -o register' states:
I've got feature class A stored in SQL Server with geometry storage, and table B. I created a view (ABView) in SSMS that joins the table to the feature class. The view includes A.Shape. I'm using Desktop 10.2.2 against SDE 10.2(.0).
First, the Register with Geodatabase context menu item is disabled for this view. Second, when I run RetisterWithGeodatabase_management against ABView I receive:
The command line help documentation does not seem to be correct, at least for views created in SQL.
The bigger issue is that (like you suggested) I am able to use 'sdelayer -o register' to register the view with the geodatabase. So how are you going to be able to register views at 10.3+? Has the behavior for RetisterWithGeodatabase_management changed at 10.3?
Nate -
I am not aware of a method to take database views and register with the geodatabase at 10.3.
I do not believe that database views were intentionally allowed to register with the geodatabase. It seems that there is somewhat of a loop hole that allows for this if the view is created with the SDE commandline tools or registered with the commandline (sdelayer -o register) first and then register with geodatabase is available in the client UI.
What is your intention or need for the database view to be registered with the geodatabase?
The administration reference you are sharing states 'table' and not view. I did find a reference in the 10.0 help regarding registering views with the geodatabase.
There is a note within the help document about registering views with the geodatabase ‘Registering a table with the geodatabase’ version 10.0
“Note: Because ArcGIS cannot add an object ID field to a view or update the values in an existing object ID field in a view, you cannot register a view with the geodatabase.”
NOTE that registering with the commandline does not also register with the geodatabase as the commandline tools are not geodatabase aware.
Melissa Jarman, no disrespect to you personally, but this is another example of why I get on soapboxes about how poor Esri's documentation is on technical limitations and implementations. To me, personally, it is a pretty sad state of affairs when a single note in 4-version old documentation (I am counting the new incremental releases as full versions because Esri's accountants do) is used to call functionality that has worked for many years a loophole and therefore it won't be addressed in the new software. One could argue that since the note doesn't exist in 10.2.x documentation, which is the current documentation, that it no longer applies, and therefore there is no loophole.
If Esri isn't going to support Nate Arnold's workflow in 10.3, Esri needs to just own it and don't try to rationalize it or blame the user.
I do not believe that database views were intentionally allowed to register with the geodatabase. It seems that there is somewhat of a loop hole that allows for this if the view is created with the SDE commandline tools or registered with the commandline (sdelayer -o register) first and then register with geodatabase is available in the client UI.
What!?! This is the workflow that Vince Angelo said, is it not?
That's what I'm trying to do - define the view in SSMS (or using CreateDatabaseView_management
- they both give the same error in the end), then register the view with the geodatabase. Vince, if that's not what you meant, please elaborate because I don't understand.
What is your intention or need for the database view to be registered with the geodatabase?
I want to create a view in the database for which (1) users do not have to get bothered by a prompt for unique ID field or SR, and (2) geodatabase metadata can be modified. Both of these were true of spatial views created with ArcSDE command line - if the capability exists at 10.2.x then I'm not aware of it - please share!!
The administration reference you are sharing states 'table' and not view. I did find a reference in the 10.0 help regarding registering views with the geodatabase.
I pulled the quote from the admincmdref directly from the document that gets installed with the ArcSDE command line tools 10.2.2 installer at %installdir%\ArcSDE\Documentation\Admin_Cmd_Refs\Support_files\admincmdref.htm. If this is indeed a loophole, then it's still there at the current release. Look in Data management commands --> sdelayer:
Yes, it does say 'table' in this documentation, but if using this command is not exactly what Vince Angelo said to do, then I'm terribly confused.
I'm trying to register an Oracle (11.2.0.1g) materalised view (polygons with multipart) with SDE 10.2 but when using, right-click>Register with Geodatabase, the table is basically corrupted.
The view is fine before the register and I can view the geometries in the preview panel but after registration, it becomes unusable.
Some of the unexpected issues encountered include:
Previously we would use the sdelayer - register command and were able to tell SDE to register the table with support for multipart geometries (na+) and had better control over the ObjectID. These options seems to be entirely gone now unless i'm missing something. Some help would be great if anyone has any ideas.
We are having similar issues with the SE_ANNO_CAD_DATA column being created in tables that contain the Oracle Spatial geometry type when we use the Register with Geodatabase tool rather than the SDE command line sdelayer -o register. Having a new column added to these tables is not ok.
If we register the layer with the command line THEN right click the layer in ArcCatalog -> manage -> Register with Geodatabase, the SE_ANNO_CAD_DATA column is not created.
Is there a way to use the Register with Geodatabase tool and NOT have the SE_ANNO_CAD_DATA column added to the table?
Thanks.
April - I tested this out and am finding the same thing. As long as you don't include the entity type of c for CAD when using the sdelayer -o register the SE_ANNO_CAD_DATA column is not created during registration with SDE or subsequently with the registration of the geodatabase. Is there a reason you cannot have this column stored in the table even if it remains empty?
I see you have a support case open on this - 01702061
Hi Melissa,
I can bring this up with a wider audience, but I think that we made a decision a long time ago to ALWAYS enable all the entity types like cad & multipart. Users are not always aware of which editing tools will write to the CAD_ANNO_DATA column, and I do not believe that we have any tools that allow you to enable it later if you realize that you need it.
I'll let you know if I get a clear response on this. In the meantime it will be useful to understand why they cannot add another field to a table that is now part of the geodatabase.
-Shannon
Thanks Shannon - I spoke to a few about this as well. I'll work with April through the Support case we have open and let you know what comes of it.
Hi Melissa,
We have been using Oracle Spatial with ArcSDE for many years and have never had the SE_ANNO_CAD_DATA column inserted. It has been a very clean separation between ArcSDE and Oracle Spatial and we would really like to keep it that way. When you register an Oracle Spatial table using the command line, everything ArcGIS needs goes into the SDE schema and the business data stays as-is and untouched.
We are a large agency with many program areas developing datasets with Oracle Spatial and there are hundreds of scripts and processes built around these datasets that could break if an additional, and unneeded column is thrown in there.
So far technical support has said there is no workaround and that column is required. As we’ve shown for many years that column really isn’t required, so please add the option to NOT have that column inserted.
We appreciate any help you can provide with this!