Select to view content in your preferred language

Why do GUID fields display as Text?

3728
11
Jump to solution
03-02-2018 10:55 AM
EricMahaffey1
Occasional Contributor

I'm currently trying to work with some tables within SQL Server that have GUID fields.  I'm running ArcGIS Desktop 10.3.1 and pulling the data through a standard database connection.  When I look at the table properties within ArcCatalog the GUID fields are listed as Data Type: GUID.  However, when I load them into ArcMap, they show as data type: String.  This is causing problems when I then try to join the query layer to another table in the database that has a matching foreign key field (that is GUID as well).  Any thoughts on this?

I also notice that when I add DB Spatial Views to ArcMap I have to identify a unique identifier field in the query layer.  However, a table does not require this.  The tables have indexed fields, so this might be the reason, but wanted to be sure.  This might be a separate topic than above though.

0 Kudos
11 Replies
TinaMorgan1
Occasional Contributor II

Since these are database tables, could they create a database view that joins the tables together in the database, then use the view as a query layer in ArcMap?  I wonder if this may remove some of the clunkiness...

Also, Esri GUID fields are associated with SQL Server uniqueidentifier data types.  You can see how to create uniqueidentifier columns in SQL Server...

uniqueidentifier (Transact-SQL) | Microsoft Docs 

"A column or local variable of uniqueidentifier data type can be initialized to a value in the following ways:+

  • By using the NEWID or NEWSEQUENTIALID functions.
  • By converting from a string constant in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, in which each x is a hexadecimal digit in the range 0-9 or a-f. For example, 6F9619FF-8B86-D011-B42D-00C04FC964FF is a valid uniqueidentifier value."

Per the second method, where it mentions converting strings...could this be a part of the underlying issue?  

How were your two tables originally created?

EricMahaffey1
Occasional Contributor

Thanks Tina.  We ended up using the same solution that you mentioned.  We created a series of DB Views to get around the field type issue with joining.  Once that was done, it didn't matter how ArcMap perceived the field types.