Thanks for the suggestion. I have also submitted a support incident since the documentation is very misleading as this time. For example, in the Command Reference of the ArcSDE Administrator guide on this page (Program Files/ArcGIS/ArcSDE/Documentation/Admin_Cmd_Ref/Support_files/admincmdref.htm) it describes the parameters to the SDELAYER command. I concluded from this sentence ("For the register operation, it also specifies whether the row ID is to be registered as USER or ArcSDE maintained.") meant I could simply use primary key column when I spatially enabled the tables. (I never considered this to be impossible because, like I said before almost every primary key in almost every SQL Server database is an identity. So I assumed nobody would design a system that ignores that fact if the system is truly enterprise capable, right? Very bad assumption on my part....) Now I realize that I should have interpreted this sentence further down in the document ("1. If you intend to register the feature class with the geodatabase, you should register the row ID column as ArcSDE maintained.") to mean that if you choose "USER" your feature class can never be edited in ArcMAP. That statement is very fine-print-like, so my gripe is ESRI needs to make this limitation more clear throughout the documentation. Better yet, ESRI needs to eliminate that limitation if ESRI wants to sell a truly �??enterprise�?� solution. I also found similar documentation in the ArcGIS help that led me astray as well in the same way. Consequently, I went a long way down the road and did not find the issue until I spatially enabled several tables using the -C <row_column_id> pointed to the identity / primary key of those tables. I was please when it all worked fine, (there is a web page interface for those tables as well as the ArcGIS Desktop and ArcGIS Server interfaces) until a tester tried to add a new feature / record in ArcMap. That's the only use case that failed testing because of this issue. Now all that stuff, the web pages, the ArcGIS Desktop and the ArcGIS Server pieces are impacted. Yes, I can work around it, but the point is I shouldn�??t have to work around using identities as my primary key. That�??s just silly.
