nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Setting the field OBJECTID as an identity for autoincrement

AlaeddineSaadaoui

I am using SQlServer database with ARCSDE 10 and I am wondering if I could set the OBJECTID field of my tables as an identity to be able to auto increment it when inserting data by using SQL queries.
Thank you in advance.
Alaeddine Saadaoui.
saadaoui@marshall.edu

OBJECTID.jpg

Clip_51.jpg

RobertKrisher_0-1751289703377.png

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

FloydBull

Does ArcSDE support columns with identity property set to True yet?

GeorgeClark

Hi Jake,

Do you know if the most recent version of ArcSDE supports column with IDENTIFY properties? It has been three years, and I was wondering it this capability is available now.

George

NataliyaLys

Thank you Jake. Is there any other way to auto-generate sequential number in a feature class, without setting "IDENTIFY" property on the column through SQL?

JakeSkinner

Hi Nataliya,

Unfortunately, this is still not supported.

NataliyaLys

Jake,

Do you know if the most recent version of ArcSDE supports column with IDENTIFY properties? I was just trying to set it up, and when I tried to edit my data in ArcMap I got the same error that you were talking about four years ago .

Thank you,

Nataliya

CarlosKrefft

I'm with Brian. It's simply ridiculous that ESRI STILL does not support a PRIMARY KEY with Identity Column sequence generator in the enterprise database they say the support! If you don't support the primary key you should not say you support the database.

That and the limitation of only being able to have one feature type per table (feature class). All other open source and proprietary geodatabases support this feature and have done so from day 1. ESRI is falling behind in a huge way on many basic levels. It makes developing with their product a nightmare.

AlpineTech

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.

VinceAngelo

Brian -

These are *user* Forums. If you want to communicate with Development, you probably
should use the Ideas site to submit an enhancement request. You'll probably want to include
a citation for the "90% of tables that exist in SQL-Server" figure -- While it probably should
be that high, in my experience that number is much lower. The decision to not use auto-
increment values was likely based on performance compared to the "i" table mechanism in
use, so it wouldn't hurt to bolster the request with any information you may have encountered
on performance improvements on identity columns in more recent SQL-Server releases.

- V

AlpineTech

Hi Alaeddine,

Currently, ArcSDE doesn't support columns with identity property set to True. Tables/Feature classes with this property cannot be edited in ArcMap or registered as versioned.

When attempting to create non-versioned edits in ArcMap you will receive an error similar to:

"Database Row Change: An unexpected failure occured.
Underlying DBMS error[Microsoft sql server Native Client 10.0: Cannot insert explicit value for identity column in table 'tableName' when IDENTITY_INSERT is set to OFF.][..tableName]."

If there is no fix for this yet, I hope this reply gets to the ESRI ArcSDE Development Team. I'm currently attempting to work around this issue using ArcSDE Version 10. At this point, if I understand this right, what you said (and I have confirmed) means we cannot spatially enable 90% of the tables that currently exist in SQL Server? What I mean by that is given a typical table (existing) in a typical database there will be a primary key on that table. So when spatially enabling an existing database holding data for, for example, facilities or equipment or trees or rocks or whatever, that table will likely have relationships to other tables via it's primary key. In SQL Server that key is almost always an identity. So like I inferred above, this is no minor limitation and I hope the development team is working hard to resolve this. In the mean time I will be re-designing the system I am building to work around this limitation.

AlaeddineSaadaoui

@JSkinn3:
Thank you very much for your help. I hope the next releases will support this option

)

JakeSkinner

Hi Alaeddine,

Currently, ArcSDE doesn't support columns with identity property set to True. Tables/Feature classes with this property cannot be edited in ArcMap or registered as versioned.

When attempting to create non-versioned edits in ArcMap you will receive an error similar to:

"Database Row Change: An unexpected failure occured.
Underlying DBMS error[Microsoft sql server Native Client 10.0: Cannot insert explicit value for identity column in table 'tableName' when IDENTITY_INSERT is set to OFF.][..tableName]."

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.