ArcGIS field data types

Every feature class and table is made up of fields that are defined by their data types.

When you create feature classes and tables, you select a specific data type for each field. A field's data type is the most important property because the data type you select determines the type of data the field can store. Additional field properties that can be set—such as precision, scale, and length of a field—are also dependent on the data type of the field.

In ArcGIS AllSource, available data types that can be applied to a field include a variety of numerical types (integers, float, double), text, date only, timestamp offset, binary large objects (BLOB), and globally unique identifiers (GUIDs). See ArcGIS data types for a complete list and additional details about each data type.

In ArcGIS AllSource, applying a data type to a field on a new or existing table or feature class can be completed using any of the following methods:

• Fields view
• Create Feature Class wizard
• Add Field geoprocessing tool
• Add Fields geoprocessing tool
• Create Table geoprocessing tool
• Create Feature Class geoprocessing tool
• Calculate Field geoprocessing tool

Choosing the best data types for your fields helps facilitate your data analysis, improves performance, and improves data integrity by ensuring that the correct data is stored within your tables and feature classes. Understanding what data types are, why they are important, and how they affect storage requirements will help you get the most out of your data.

ArcGIS data types

ArcGIS works with a number of data types to store and manage attribute values in the geodatabase.

Note:

Starting with ArcGIS AllSource 3.2 new field data types are supported in geodatabases, databases, cloud data warehouses, and text files. To opt out of using these new field data types when accessing unregistered data through a layer, ensure the Use field types that are compatible with ArcGIS Pro 3.1 and earlier releases when adding query layers and text files option is enabled in the ArcGIS AllSource settings. This option applies to layers and does not apply when accessing the data directly from the data source.

The supported attribute data types in a geodatabase include the following:

Tip:

Click the links below to learn more about each data type.

• Numbers—Can be one of the following numeric data types:
  • Short—Short integers (16-bit)
  • Long—Long integers (32-bit)
  • Big integer—Big integers (64-bit)

    Caution:

    Some client applications may not fully support this field type and are subject to change. Object ID (64-bit) and big integer (64-bit) field types in ArcGIS AllSource are limited to storing values up to 53-bit safe integers. 53-bit safe integer values support a range between (-9007199254740991) and (9007199254740991), which is also written as -(2 ⁵³) -1 and (2 ⁵³) -1. Values larger than 53 bits in object ID (64-bit) and big integer fields added from external sources can be read from the ArcGIS AllSource client. Attempting to write or edit numbers outside this range in ArcGIS AllSource will generate an error. In other clients, the value may be rounded and result in broken functionality.

  • Float—Single-precision (32-bit) floating point numbers
  • Double—Double-precision (64-bit) floating point numbers
• Text—Any set of alphanumeric characters of a specified length.
• Date and Time—Can be one of the following date or time data types:
  • Date—Date and time values
  • Date only—Date values only with no time values
  • Time only—Time values only with no date values
  • Timestamp offset—Date, time, and offset from UTC value
• BLOB—Binary large objects are used to store documents, photographs, or other large data.
• Global identifiers—Can be one of the following:
  • GUID—Data types store registry-style strings consisting of 36 characters enclosed in curly brackets. These strings uniquely identify a feature or table row within a geodatabase and across geodatabases. These are heavily used to manage relationships, especially for data management, versioning, change-only updates, and replication.
  • Global ID—Global IDs uniquely identify a feature or table row in a geodatabase and across geodatabases.
• Object ID—An object identifier is a unique integer field that cannot have null values and is added when a geodatabase table or feature class is created in ArcGIS. This object ID field stores a unique ID for each row in the table and is created in tables and feature classes as a 32-bit object ID by default. If an object ID field needs to store values larger than 2.14 billion, the object ID field can be migrated to 64-bit object IDs using the Migrate Object ID To 64 Bit geoprocessing tool.

  Caution:

  Some client applications may not fully support this field type and are subject to change. Object ID (64-bit) and big integer (64-bit) field types in ArcGIS AllSource are limited to storing values up to 53-bit safe integers. 53-bit safe integer values support a range between (-9007199254740991) and (9007199254740991), which is also written as -(2 ⁵³) -1 and (2 ⁵³) -1. Values larger than 53 bits in object ID (64-bit) and big integer fields added from external sources can be read from the ArcGIS AllSource client. Attempting to write or edit numbers outside this range in ArcGIS AllSource will generate an error. In other clients, the value may be rounded and result in broken functionality.

• Raster— A raster data type can be added to a geodatabase feature class or table, and can store the raster data in or alongside the geodatabase. Rasters are not supported in mobile geodatabases.

Note:

File and mobile geodatabase data types are the same as ArcGIS data types. For database management systems (DBMS), though, ArcGIS data types map to database data types and can differ depending on the DBMS. To learn more about how ArcGIS data types map to DBMS data types, see Database data types supported in ArcGIS.

Numbers

You can store numbers in one of the following numeric data types:

• Short—Short integers (16-bit)
• Long—Long integers (32-bit)
• Big integer—Big integers (64-bit)
• Float—Single-precision (32-bit) floating point numbers
• Double—Double-precision (64-bit) floating point numbers

The table below provides a summary of numerical data types, their ranges, and storage requirements. The ranges in this table are listed for file and mobile geodatabases. Ranges differ slightly in databases and enterprise geodatabases.

ArcGIS numerical data types summary table

Data type	Storable range	Size (bits)	Application
Short integer	-32,768 to 32,767	16	Numeric values without fractional values within a specific range; coded values
Long integer	-2,147,483,648 to 2,147,483,647	32	Numeric values without fractional values within a specific range
Big integer	-9,007,199,254,740,991 to 9,007,199,254,740,991	64	Numeric values without fractional values within a specific range
Float (single-precision floating-point number)	Approximately -3.4E38 to 1.2E38	32	Numeric values with fractional values within a specific range
Double (double-precision floating-point number)	Approximately -2.2E308 to 1.8E308	64	Numeric values with fractional values within a specific range

When choosing a data type to store numbers, consider the following:

• Determine how best to store numerical data—Whole numbers or fractional numbers
  • Whole numbers—If you need to store whole numbers with no decimal places, such as 4; 5575; 101,272; or a value that exceeds 2.14 billion, specify short, long or big integer, respectively.

    Note:

    In ArcGIS AllSource, the field's data type is displayed as short or long instead of short integer or long integer.

  • Fractional numbers—If you need to store numbers with a decimal, you can specify a float or double data type. When using a float or double (sometimes referred to as a single- or double-precision floating point), the decimal point can be in any position in the field and, thus is said to float from one location to another for different values stored in the field.

• Use a data type that consumes the least storage space.

  When creating a field in ArcGIS AllSource, it is recommended that you choose the data type that consumes the least storage space to improve performance. In some instances, when creating a field, the field's data type changes to long integer despite specifying the data type as short integer. Computers can only store a limited number of digits, depending on the storage space being allocated.

  When choosing between short integer, long integer, and big integer, or between float and double, choose the data type that takes up the least storage space for the number ranges you need to store. This minimizes the amount of storage required and also improves performance.

  For example, to store integers between -32,768 and 32,767 only, specify the short integer data type, because it takes up 2 bytes, whereas the long integer data type takes up 4 bytes. To store fractional numbers between -3.4E38 and 1.2E38 only, specify the float data type because it takes up 4 bytes, whereas the double data type takes up 8 bytes.

You can format a numeric field type to give additional context to an attribute so that it is more than a number. Numeric field formatting is a layer property that can be set only in the current map.

See Format numeric and date fields to learn how to apply numeric formatting to a field in a layer or stand-alone table.

Short

The short data type is a 16-bit signed integer that can only store whole number values within the range of -32,768 to 32,767. You cannot store a value greater than 32,767 or less than -32,768 in a short integer field, even if you set the precision to 5. For example, whole values of 4, 515, or 29715 can be stored in a short integer field.

Long

The long data type is a 32-bit signed integer that can store whole number values within the range of -2.14 billion to 2.14 billion. You cannot store a value greater than 2,147,483,648 or less than -2,147,483,647 in a long integer field.

Big integer

The big integer data type is a 64-bit signed integer that can store very large whole number integer values with the range of -(2 ⁵³) -1 and 2 ⁵³ -1 and has a storage size of 8 bytes. If you need to store whole numbers that exceed the long integer data type range of -2.14 billion to 2.14 billion, use a big integer data type.

Caution:

Some client applications may not fully support this field type and are subject to change. Object ID (64-bit) and big integer (64-bit) field types in ArcGIS AllSource are limited to storing values up to 53-bit safe integers. 53-bit safe integer values support a range between (-9007199254740991) and (9007199254740991), which is also written as -(2 ⁵³) -1 and (2 ⁵³) -1. Values larger than 53 bits in object ID (64-bit) and big integer fields added from external sources can be read from the ArcGIS AllSource client. Attempting to write or edit numbers outside this range in ArcGIS AllSource will generate an error. In other clients, values may be rounded and result in broken functionality.

Float

A float data type is a single-precision 32-bit floating point number that can precisely store numbers that contain up to six digits only. For example, you could not store the number 515297.15 precisely in a float field, because this number contains more than six digits. You can type the number in a float field in a file geodatabase, but it will be rounded to 515,297, which is a number containing the permissible six digits. If you need to store this number precisely, store it in a double field. Float fields in databases and enterprise geodatabases do not allow you to specify more digits than the precision for the field, so no rounding takes place.

Double

A double data type is a double-precision 64-bit floating point number that can precisely store numbers that contain up to 15 digits only in databases and geodatabases, because this is the longest number that can fit into 8 bytes of storage space. Numbers that have more digits than this are rounded and stored in a format similar to scientific notation, making them approximate numbers only. For example, if you type a 20-digit number such as 12,345,678,901,234,567,890, it is rounded and stored as the 15-digit number 1.23456789012346E+19. The coded value at the end, E+19, defines the placement of the decimal point.

Precision and scale

The precision and scale property of a field represent the maximum precision and size of data that can be stored in the field.

The meaning of the precision property differs for some field types, such as date and numeric fields. For numeric fields, precision represents the maximum total number of digits that can be stored in the field. All digits are counted no matter what side of the decimal they are on. For date fields, precision refers to their capacity to record millisecond values. A standard date field records time to the second and displays a precision value of 0. A date field that has been migrated to high precision records time to the millisecond and displays a precision value of 1.

Scale is a field property that is only used for float or double data types and represents the number of digits to the right (if positive) or left (if negative—rarely used) of the decimal point in a number. For example, the number 4703338.13 has a scale of 2 and a precision of 9.

Specifying the precision and scale allows you to restrict the range of values and number formats a field can accept, giving you greater control. For example, if you specify a float with a precision of 4 and a scale of 2, the field will accept 46.22. If you try to enter 46.223 in the field, an error message appears, as this exceeds the maximum number of digits and decimal places allowed. Alternatively, if you specify a float with a precision of 5 and a scale of 3, you can store the value 46.223.

Precision and scale in a file or mobile geodatabase

File and mobile geodatabases do not display precision or scale values because they cannot be defined by the user. Therefore, if you add numeric fields to a table or feature class in a file or mobile geodatabase, you need only specify the data type. If you provide a value for precision or scale, it will be ignored and the precision and scale properties will not display in the fields view.

Fields of data type float in file or mobile geodatabases can precisely store numbers that contain up to six digits only. For example, you cannot store the number 410534.208 precisely in a float field, because this number contains more than six digits. You can type the number in a float field in a file geodatabase, but it will be rounded to 410534, a number containing the permissible six digits. Therefore, to store the number 410534.208 precisely, you must store it in a double field.

Precision and scale in a database or enterprise geodatabase

If you add a numeric field to a table or feature class in a database or enterprise geodatabase, you can specify the precision (the maximum length of the field). If the field is a float or double data type, you can also specify the scale (the maximum number of decimal places) for field values. Float fields in enterprise geodatabases and databases do not allow you to store more digits for the scale than the number of digits used for the precision of the field, so no rounding occurs.

The table below provides a summary of the precision and scale values that can be specified when you add a field in fields view. Precision must always be larger than scale. Scale does not apply to integer types because they do not store decimal values. Use this information to help you choose data type, precision, and scale.

Data type	Precision (field length)	Scale (decimal places)
Short integer*	1–5 (Oracle) 5 (IBM Db2, Microsoft SQL Server, and PostgreSQL)	0
Long integer	6-10 (Oracle) 6–9 (Db2) 10 (SQL Server and PostgreSQL)	0
Big integer	11–18 (Oracle) 10-18 (Amazon Redshift) 10-18 (Snowflake)	0
Float	1–6	1–6
Double	7+	1+

*By default in ArcGIS AllSource, short integers are created with a precision of 5. However, short integer columns can only store values within the range of -32,768 to 32,767. You cannot store a value greater than 32,767 or less than -32,768 in a short integer field, even if you set the precision to 5. There is no reason to specify a precision for short integer columns created in ArcGIS AllSource on a database other than Oracle.

The following table provides examples of number ranges and how you can store them in a database or enterprise geodatabase:

Examples of number ranges, data types, precision, and scale

Storable range	Data type	Precision (field length)	Scale (decimal places)
0 to 99	Short integer	2	0
-99 to 99*	Short integer	3	0
-32,768 to 32,767*	Short integer	5	0
-99,999 to 99,999*	Long integer	5	0
-9,007,199,254,740,991 to 0*	Big integer	19	0
0 to 9,007,199,254,740,991	Big integer	18	0
0.001 to 0.999	Float	4	3
1,000.00 to 9,999.99	Float	6	2
-123,456.78 to 0*	Double	9	2
0 to 1,234.56789	Double	9	5

*Negative numbers require additional precision to store the negative sign.

Text

A text field represents a series of alphanumeric symbols. This can include street names, attribute properties, or other textual descriptions. An alternative to repeating textual attributes in a geodatabase is to establish a coded value. In this case, a textual description is coded with a numeric value. For example, you can code road types with numeric values by assigning a 1 to paved improved roads, a 2 to gravel roads, and so on. This has the advantage of using less storage space in the geodatabase; however, the coded values must be understood by the data user. If you define coded values in a coded value domain in the geodatabase and associate the domain with the integer field storing the codes, the geodatabase will display the textual description when the table is viewed in ArcGIS AllSource.

Learn more about subtypes and attribute domains.

The characters used for text vary by language. To allow text to more easily convert between languages, ArcGIS uses Unicode to encode characters.

Date and time

Many datasets store date and time (temporal) information. Date and time values might represent when a feature was in a specific location or when a feature was first observed in the real world. Or the date and time might relate to other nonspatial attributes in the layer, such as when a property was sold, the last time a sample was taken from a specific water body, or the date and time a fire engine was dispatched from a specific fire station.

You can store temporal values in one of the following date or time data types:

• Date—Date and time value precision in seconds (low precision) or milliseconds (high precision).

  Tip:

  Beginning with ArcGIS Pro 3.2, you can migrate date fields in a table to high precision to support millisecond time.

• Date only—Date values only with no time values
• Time only—Time only values up to seconds only precision with no date values
• Timestamp offset—Date, time, and offset from the Coordinated Universal Time (UTC) zone

  

Caution:

ArcGIS Pro 3.1 and earlier cannot access geodatabase tables or feature classes that contain fields of the following data types: date only, time only, timestamp offset, big integer, or 64-bit object IDs. Although you can publish these data types to ArcGIS Enterprise 11.3, they are not fully supported and their use in ArcGIS Enterprise 11.3 web layers is considered beta functionality.

Some of the tools in which the date and time data types can be accessed include the fields view, the Add Field geoprocessing tool, the Create Feature Class wizard, and the Create Feature Class geoprocessing tool.

In ArcGIS AllSource, you can view and manage these fields of a layer or table in the fields view. This allows you to model the attributes that are shared by a collection of features or objects in a table. In the fields view, you can edit the fields and their properties, delete fields, and create new ones.

Learn more about how to create, delete, and modify fields of a layer or table

You can choose from multiple date formats to apply to the Date category. Applying formatting to a date or time field type helps provide additional context to and improve the readability of date and time values. Date field formatting is a layer property that can be set for layers in the current map only. See Format numeric and date fields to learn how to apply date formatting to a field in a layer or stand-alone table.

The table below provides a summary of the date and time data types, their format, and examples of formatting and use cases.

ArcGIS date and time field types summary

Date and time field type	Description	Date and Time format	Examples	Use cases
Date	The field type is date. Date fields support date and time values up to a precision of seconds only.	MM/DD/YYYY hh:mm:ss (Default) DD/MM/YYYY hh:mm	Date + Time 5/16/2008 8:12:15 PM 4/20/2011 10:30:12 AM	Time values that are either all in UTC or all within the same local time zone. Weather data Date and time of restaurant inspections for a county
Date (high precision)	Date fields can be migrated to high precision to support millisecond time values.	High-precision date field MM/DD/YYYY hh:mm:ss.sss	Date + High-Precision Time 5/16/2008 8:12:15.172 PM 4/20/2011 10:30:12.869 AM	High-precision time values that are either all in UTC or all within the same local time zone. Timestamp values acquired by sensors such as traffic cameras Date and time of lightning strikes
Date only	The field type is date only. Date-only fields support date values with no time values.	MM/DD/YYYY (Default) DD/MM/YYYY YYYY	Date 9-29-2023 12-06-2022 14-07-1964 2005	Data that was captured in the granularity of days or attribute values that apply to, or represent, the entire day. Birth date Start or end date of a school semester Aggregating total number of hurricanes based on the year they occur
Time only	The field type is time only. Time-only fields support time values with no date value.	hh:mm:ss (Default) hh:mm	Time 15:35:23 10:00 AM	Data that repeats daily or content for which only the time component matters. Business or store hours Bus or train schedule Zoo tracking animals' daily feeding routine
Timestamp offset	The field type is timestamp offset. Timestamp offset fields support a date, time, and time zone offset from the Coordinated Universal Time (UTC) zone.	MM/DD/YYYY hh:mm:ss.sss zzz (Default)	Date + Time + UTC offset 2/8/2022 3:54:00.268 PM -04:30 3/10/2008 2:57:03.172 AM +09:00 9/30/2011 10:11:01.432 PM -05:00 5/12/2023 8:43:56.162 AM +00:00	Time values for which the local time value is important and the dates can cross multiple time zones. Crimes Date and time of an earthquake Traffic incidents Airline managing departure and arrival schedules worldwide, while also understanding the local time for passengers

You can create or update a feature class or table with these new date and time field types in a file, mobile, and enterprise geodatabase. Some of the new date and time field types are not supported depending on the database used, and you might not be able to add some of the new date and time field types. When adding a field to a table or feature class, if the data type chosen is not supported for the workspace, you'll see the following error: The data type is not supported by the workspace. You must use a data type that is supported for the workspace.

To learn more about the data types supported in various database workspaces, see Database data types supported in ArcGIS and Cloud data warehouse data types supported in ArcGIS.

Date

Whether you're displaying, calculating, or selecting date attributes, you must determine the appropriate way to work with the date data type in ArcGIS AllSource. Geodatabase data sources store dates using the date data type. The date data type can store dates, times, or dates and times. The default format in which the information is presented is mm/dd/yyyy hh:mm:ss and a specification of AM or PM. When you type date fields in the table through ArcGIS, they are converted to this format.

Note:

• Date fields support date and time values, are always created as low precision, and support storing time values up to seconds-only precision, by default.
• In ArcGIS AllSource, you cannot insert or view a date value older than 100 CE. If you use a date type that stores time, a time of 00:00:00 is equivalent to 12 a.m. (midnight).

If you calculate a date field's values to populate the field or query the field, dates must be typed in MM/DD/YYYY hh:mm:ss format, enclosed in single quotation marks. Storing time alone in a date field is not supported; time must always be a component of a date. If you do not provide a time, the time defaults to 12:00 a.m. ArcGIS AllSource uses the system short date format (numerical) to display dates.

Settings on your Microsoft Windows system determine how the dates display in ArcGIS AllSource, for example, M/D/YY, MM/DD/YY, YY/MM/DD. ArcGIS AllSource uses the system short date format (numerical) to display dates. While these are the default formats, dates can also be formatted to display differently in the table and a pop-up.

Selecting and displaying date field values using the Select Layer By Attribute geoprocessing tool and similar query-building dialog boxes is done using an SQL syntax. The SQL syntax used to select and display date field values varies based on the type of database. This is described in detail in the SQL reference for query expressions used in ArcGIS topic.

Migrate date field to high precision

Use the Migrate Date Field To High Precision geoprocessing tool to migrate date fields in a table to high precision. High-precision date fields allow the time value in a date field to support fractional seconds up to the thousandths place or milliseconds and will display as MM/DD/YYYY hh:mm:ss.sss.

Migrating the date field to high precision enables time values to support fractional seconds up to millisecond precision.

Caution:

• ArcGIS Pro 3.1 and earlier clients cannot access geodatabase tables or feature classes that contain date fields that have been migrated to include millisecond time values.
• Once a date field has been migrated to high precision, it cannot be undone on the field. To revert the date data back to a low-precision date, create a new date field (low precision), and use the Calculate Field geoprocessing tool to populate this new date field (low precision), from the high-precision date field.

In ArcGIS AllSource, the asterisk (*) symbol indicates that a special property is associated with a particular field. Once you have migrated a date field to high precision, an asterisk will appear next to the high-precision date field name in the Fields view.

Note:

When you import high-precision date fields in the Create Feature Class wizard, they import as low-precision dates. Importing an XML workspace document with high-precision date fields will preserve the high-precision date values.

Date only

The date only data type represents a specific date, without time. Since it has no time component, it represents a date from the start of the day to the end of the day. This structure is ideal for storing specific dates, such as a birth date, an anniversary date, a holiday, or a business-related date.

Although you could use the date data type while ignoring the time component, one of the benefits of using the date only type over the date type is that the date data type may roll into the previous or next day if it's offset by a time zone. Date only can't be offset by a time zone, and it always represents the date that was set.

Formatting options in ArcGIS AllSource for the date only data type only change how the data values are displayed and does not affect how the data is stored or how the data can be entered. For example, the following image shows formatting examples for the date only data type.

See Format numeric and date fields to learn more.

Time only

The time only data type represents a 24-hour period of time and can be used to replace the date data type when you only need to represent a time. Since the time only data type represents the hours, minutes, and seconds of a nonspecific day, the time of day values for this data type are limited to a range of 00:00:00 - 23:59:59. Formatting options in ArcGIS AllSource for time only fields only change how the time values are displayed; they do not affect how the data is stored or how data can be input. See Format numeric and date fields to learn more.

Because the time only data type represents a time-of-day value, the time rolls forward and backward appropriately around the 24-hour time frame when adding values.

The following are some examples:

• If an employee's work shift starts at 18:00 and lasts 8 hours, adding 8 hours to the time only value would roll over to 2:00.
• If the closing time for a business is stored as 01:30:00 to represent 1:30 a.m., and they've recently decided to close four hours earlier on Mondays and Tuesdays, subtracting four hours from 01:30:00, rolls the new closing time value backward to 21:30:00, which is 9:30 p.m.

Formatting options in ArcGIS AllSource for the time only data type only change how time values are displayed, they do not affect how the time values are stored or how time values can be input. For example, the following image shows formatting examples for the time only data type.

See Format numeric and date fields to learn more.

Timestamp offset

The timestamp offset data type includes all of the functionality of the date data type along with time zone awareness and makes it possible to work with dates and times so that any date and time value unambiguously identifies a single point in time. The timestamp offset is the difference (in hours and minutes) between local time and UTC (Coordinated Universal Time, formerly Greenwich mean time).

Use the timestamp offset data type to work with dates and times whose offset (or difference) from UTC is known. The timestamp offset data type combines a date and time value with that time's offset from UTC. Because of its relationship to UTC, an individual date and time value unambiguously identifies a single point in time. This makes a timestamp offset value more portable from one computer to another than a date value.

Although a timestamp offset value includes an offset, it is not a fully time zone-aware data structure. While an offset from UTC is one characteristic of a time zone, it does not unambiguously identify a time zone. Not only do multiple time zones share the same offset from UTC, but the offset of a single time zone changes if it observes daylight saving time.

Formatting options in ArcGIS AllSource for the timestamp offset data type only change how values are displayed; they do not affect how the values are stored or how values can be input. For example, the following image shows formatting examples for the timestamp offset data type.

See Format numeric and date fields to learn more.

Global identifiers

Global ID and GUID data types store registry-style strings consisting of 36 characters enclosed in curly brackets. Global IDs are only supported in geodatabases. In all geodatabases except those in Microsoft SQL Server, global IDs are stored in text fields, and the characters stored in a text global ID field are always uppercase characters.

When generating global IDs, the process takes into consideration the device and time. Given the negligible probability of generating duplicate values, these strings are used to uniquely identify a feature or row in a table in a geodatabase and across geodatabases. This is how features are tracked in one-way and two-way geodatabase replication. Developers can use them in relationships or any application requiring GUIDs. In a relationship, if a global ID field is the origin key, a GUID field must be the destination key. You can add global IDs to a dataset in a geodatabase using the Add Global IDs geoprocessing tool. The geodatabase then maintains these values automatically. You can create a GUID field as well, but you must maintain its values.

Databases with a native GUID data type, such as SQL Server, store global ID and GUID values as 16 bytes. Databases without a native GUID data type store them as 38 bytes.

Notes on global IDs

Keep the following in mind when using global IDs:

• GUID fields can be added to geodatabase datasets using the fields view or the New Field command in the table window.
• You can add global IDs to stand-alone feature classes, tables, and attributed relationship classes in geodatabases. Global IDs cannot be added to individual datasets in a feature dataset; when you enable global IDs on a feature dataset, they are added to all the datasets in the feature dataset.
• Global IDs cannot be added to tables in a database.
• If there is an existing global ID column, the Add Global IDs tool leaves the old column; it doesn't drop the existing global ID column and add a new one.
• If you add a feature class to a feature dataset in a geodatabase and want to add a global ID column to it, you must run the Add Global IDs tool on the feature dataset. This adds a global ID column to the new feature class. Feature classes in the feature dataset that have an existing global ID column remain unchanged.
• Copying and pasting, data extraction, and XML workspace exporting and importing preserve global ID values in the output geodatabase, thus it is possible to have nonunique global IDs in a database. Other data exporting and importing methods do not preserve these values.

Object identifiers

When you create a table in ArcGIS, a unique integer field that cannot be null is added to the table to act as an object identifier (object ID). The object ID field is maintained by ArcGIS and guarantees a unique ID for each row in the table. When you look at a table or a layer's attribute table, you usually see the object ID field listed under the aliases of OID or ObjectID for tables and FID for web feature layers and shapefiles. Key functions, such as scrolling and displaying selection sets, depend on the presence of this field.

An object ID is also required when you register a table with an enterprise geodatabase. For an explanation of object ID requirements when registering a table, see Register a table or view with the geodatabase.

Most ArcGIS AllSource functionality, such as using the Identify tool, requires the values in the object ID field to be unique. Therefore, use caution when working directly with the data outside of ArcGIS so that object IDs are not duplicated. For example, when you create a view in a database with a one-to-many relationship, it is possible that object IDs will be duplicated. This causes inconsistent behavior in ArcGIS AllSource functionality.

When you add a database table to the map, an object identifier is needed. If ArcGIS cannot find a nonnull integer field to use as an object identifier, you are prompted to choose a field to be used as the object identifier. See Unique identifier fields for more information.

Note:

ArcGIS does not maintain the values in these database fields, and it is not guaranteed that all values in these fields are unique.

64-bit object IDs

Geodatabase tables and feature classes are created in ArcGIS with 32-bit object IDs, by default. However, there are circumstances when object ID values need to be greater than 2.14 billion. For example, you may need to model a dataset with more than 3 billion utility features, or you may need to work with tables in cloud data warehouses with multibillion rows.

The Migrate Object ID To 64 Bit geoprocessing tool accepts one or more geodatabase feature classes or tables as input datasets and migrates their object ID fields to a 64-bit object ID field.

Caution:

Some client applications may not fully support this field type and are subject to change. Object ID (64-bit) and big integer (64-bit) field types in ArcGIS AllSource are limited to storing values up to 53-bit safe integers. 53-bit safe integer values support a range between (-9007199254740991) and (9007199254740991), which is also written as -(2 ⁵³) -1 and (2 ⁵³) -1. Values larger than 53 bits in object ID (64-bit) and big integer fields added from external sources can be read from the ArcGIS AllSource client. Attempting to write or edit numbers outside this range in ArcGIS AllSource will generate an error. In other clients, the value may be rounded and result in broken functionality.

The Migrate Object ID To 64 Bit geoprocessing tool can be used to migrate the object ID field of feature classes that participate in a topology or parcel fabric by providing the feature dataset as the Input Dataset value. Additionally, the tool also supports migrating the object ID field of a relationship class.

Caution:

When an object ID field is migrated to store 64-bit object IDs, the change cannot be undone and the dataset can no longer be used with ArcMap or previous versions of ArcGIS AllSource.

To determine whether a feature class or table can store 32-bit object IDs or 64-bit object IDs, right-click the feature class or table in the Catalog pane, or right-click the layer in the Contents pane, and click Properties > Source > Data Source. The supported bit level is listed in the ObjectID row.

Raster

Unlike a hyperlink that only links a feature's field to an image, a raster field data type can store the raster data in or alongside the geodatabase. All supported raster dataset formats are available, but it is recommended that only small pictures are used for this field. Only one field of type raster can be used in each table. To learn more, see Adding raster datasets as attributes in a feature class.

Note:

Mobile geodatabases do not support raster columns; however, they support the use of attachments to associate nongeographic data, such as photos or documents, to a feature.

Learn more about working with the Attachments geoprocessing tools

Geometry

In ArcGIS, the geometry data type indicates the type of geometry—point, line, polygon, multipoint, or multipatch— that the table stores. The field stored as geometry type is named SHAPE when created through ArcGIS.

Geometry is the data type used by ArcGIS. For example, if you choose Polygon Features for a new feature class, the SHAPE field added by default has an ArcGIS data type of geometry.

For the Geometry Type parameter of the Create Feature Class tool, the default geometry type is polygon.

If you create a feature class with a different feature type—line, point, multipoint, multipatch, dimension, or annotation—the geometry type for the SHAPE field changes accordingly to line, point, multipoint, multipatch, or polygon for dimension and annotation.

Each feature class can contain only one geometry type field.

When you create a geometry field in a feature class in a database or enterprise geodatabase, you must also consider the database data type. How geometry values are stored in a DBMS depends on the geometry storage type used by the DBMS. When you create a feature class in an enterprise geodatabase, the geometry storage type used is determined by the GEOMETRY_STORAGE parameter setting of the configuration keyword you specify. When you use ArcGIS to create a feature class in a database, you define the spatial type of the field in the Configuration Keyword parameter in the Geodatabase Settings section of the Create Feature Class tool.