GlobalID data type showing as "SmallInteger"

[StormwaterWater_Resources]

ArcMap Standard, 10.1:

I'm using the following:

inputField = arcpy.ListFields(inputLayer, inputFieldName)[0]
fieldType = inputField.type

For everything except GlobalID's it's working fine.  When the data type is a GlobalID the returned value of .type is "SmallInteger".  I can't find any forum or help page showing this to be a known bug.  How do I find the type of a global ID field?

[MathewCoyle]

Edit: Sorry read GlobalID as OID.

I'm not sure exactly how GUIDs work but I'm assuming the actual field value is just a reference to a value stored in the geodatabase, similar to a domain.

[StormwaterWater_Resources]

[INDENT]

I'm not sure exactly how GUIDs work but I'm assuming the actual field value is just a reference to a value stored in the geodatabase, similar to a domain.

[/INDENT]

I'm not sure either, but I don't think so.  It's seems clear from this:

   http://resources.arcgis.com/en/help/main/10.1/index.html#//003n0000001m000000

that they're just the 36 character strings as described.  Furthermore I was able to fix this problem by using this code:

        # Begin bug patch of Guid showing as ShortInt
        rows = arcpy.SearchCursor(layer)
        for row in rows:
            TestString = str(row.getValue(fieldName)) # use str() in case this really is a Short
            if (TestString[0] == "{"):   # a "{" character has no business in a *real* Short
                valueDelimiter = "'"
        # End bug patch of Guid showing as ShortInt

Am I missing something obvious?

PS: I'm building up a query string.  Some values need delimiters (e.g. strings and guids) and some don't (e.g. short integers).

[MathewCoyle]

Yes but the string is registered with the geodatabase, it does not necessarily have to be the value stored in the field.

[StormwaterWater_Resources]

Yes but the string is registered with the geodatabase, it does not necessarily have to be the value stored in the field.

Ok, but how does that help?

I need to properly delimit a value in an SQL query (the delimiting of the field name per workspace is already done).  If it's a short then the form is

[FieldName] = [value]

if it's a guid then it's

[FieldName] = '[value]'

How does it help if the guid is a reference or not?  It still doesn't seem right that the .type property should return "SmallInteger" on something which is clearly neither small nor an integer.


EDIT: PS: Oh, are you saying the SmallInteger is a reference to the guid?  Shorts do not even remotely map onto the domain space of a guid so that's definitely not the case if I'm understanding what you mean.

[MathewCoyle]

Yes you are right of course, I was just speculating on possible scenarios where this wouldn't be a bug/error but it definitely seems like it is. I tested on a sample feature class over 65,535 rows of GUIDs and it is still assigned a type of SmallInteger which has to be a bug no matter what the field holds.

Not sure if this helps your situation, but are you aware of the describe properties for GUIDs?

desc.globalIDFieldName
desc.hasGlobalID

[StormwaterWater_Resources]

I had played with the describe method earlier when trying to use it for determining the delimiters for the field name, but I didn't remember that there were globalID properties in the desc object.  Thank you, I'll look at that tomorrow.  None the less, as you saw the .type value for guids clearly seems to be broken so I'm hoping someone from Esri will notice this.

[AJR]

I'm seeing this same error with 10.2.1, seems like a bug, here's the result from the describe function

>>> for fld in desc.fields:
...     print(fld.name + " " + fld.type)
...     
OBJECTID OID
COMMENTS String
NAME String
YEARESTABLISHED Date
MXPARENTLOC String
CREATEEDITOR String
CREATEDATE Date
LASTEDITOR String
LASTEDITDATE Date
Shape Geometry
GlobalID SmallInteger
Shape.STArea() Double
Shape.STLength() Double
>>>

but the field shows as a GlobalId type in ArcCatalog

[JoshuaBixby]

What is the back-end data store?  SQL Server, Oracle, PostgreSQL?

I did a quick check using ArcGIS 10.5 with an enterprise geodatabase in SQL Server, and the results are correct with ArcPy Describe.

[AJR]

Might be fixed in 10.5, but with 10.2 with Sql Server backend enterprise gdb the issue occurs.

A.J.