Is it possible to use the Identity property within SQL Server for a feature class?
Is this to be a simple feature class with a native geometry type, or registered with the geodatabase and versioned?
Is there a certain criteria where it would work and where it wouldn't? For a typical feature class, registered with the geodatabase, versioned or non-versioned (if versioned, I'm assuming it'd need to be on the A table if it would work).
I'm really just after a good way of assigning an auto-incremented field in the table that is NOT the OBJECTID.
"Possible" and "supported" are different standards. You can sometimes get away with some unsupported types if they look close enough to supported types, but only if you don't press the issue too strongly. Identity columns are not supported in versioned geodatabases.
I can't be the only person after an auto-incremented field within the database. Is there a way of doing this within SSMS with a trigger, stored procedure, etc...?
Were you able to find a workaround? We are trying to auto-assign and ID that is not the ObjectID so we can use it in other downstream processes.
I haven't found what I'm really after...which is a database driven method for assigning an identifier separate from the OBJECTID. I'm not a DBA and don't want to be, so I'm not researching advanced methods with the DBMS. We have recently updated our DB server to SQL Server 2014 which can use sequences, but again, that's out of my realm of understanding.
We have found a work-around that is ArcMap driven. By using the Attribute Assistant tools, we can create GenerateId rules which will sequential number features in a feature class and/or table. The Attribute Assistant is part of the Water Utility Network Editing tools. There are several other ways the Attribute Assistant tools can be used, are really are very handy, but they are only available inside an ArcMap session.
You could pull a trigger to update/populate a given field. (see this very old post of mine Standard disclaimer: Your Mileage May Vary; Use at Your Own Risk.)
I do use the object id to populate a 'static' id field in some cases. For example, I use database replication from SDE/SQL Server to a File GDB, replicating a feature class along with an alias table of the features. I use the SDE/SQL object id to populate my relate/join field. That way, when I replicate I'm ensured a unique value in the child database. I don't do this with a trigger as I'm adding a new feature along with a row or two or three in the alias table.
Retrieving data ...