When you create feature classes and tables, you select a data type for each field. The available types include a variety of number types, text types, date types, binary large objects (BLOBs), or globally unique identifiers (GUIDs). Choosing the correct data type allows you to correctly store the data and will facilitate your analysis, data management, and business needs.
The data types explained in this topic include the data types available when creating a feature class or table with ArcGIS. If you store your data in a database or a geodatabase in a database management system (DBMS), ArcGIS data types and the data types of the DBMS might not match directly. The types are matched to the closest data type available in the DBMS. This process is referred to as data type mapping. In this process, it is possible that the values will be stored in the DBMS as a different type, applying different criteria to the data attribute. As a result, the data type you see in the table or feature class properties in ArcGIS Pro may change from what you initially defined.
Additionally, other data storage formats, such as shapefiles or dbf tables, have different data type limitations. Be sure you know the data type and size limitations of your destination storage format when moving data between data storage types.
You can store numbers in one of four numeric data types:
- Short integer
- Long integer
- Float (single-precision floating-point numbers)
- Double (double-precision floating-point numbers)
In choosing the data type, first consider the need for whole numbers versus fractional numbers. If you just need to store whole numbers, such as 12 or 12,345,678, specify a short or long integer. If you need to store fractional numbers that have decimal places, such as 0.23 or 1234.5678, specify a float or a double.
Secondly, when choosing between a short or long integer or between a float or double, choose the data type that takes up the least storage space. This will not only minimize the amount of storage required but will also improve performance. If you need to store integers between -32,768 and 32,767 only, specify the short integer data type, because it takes up only 2 bytes, whereas the long integer data type takes up 4. If you need 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. The following table lists data types, their ranges, and storage requirements. The ranges listed are for file and personal geodatabases. Ranges differ slightly in databases and enterprise, workgroup, and desktop geodatabases.
-32,768 to 32,767
Numeric values without fractional values within specific range; coded values
-2,147,483,648 to 2,147,483,647
Numeric values without fractional values within specific range
Float (single-precision floating-point number)
approximately -3.4E38 to 1.2E38
Numeric values with fractional values within specific range
Double (double-precision floating-point number)
approximately -2.2E308 to 1.8E308
Numeric values with fractional values within specific range
If you're specifying numeric fields for a table in a file geodatabase, you need only specify the data type. If you're specifying numeric fields for a database or enterprise geodatabase, also specify the precision (the maximum length of the field) and scale (the maximum number of decimal places).
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 12.34. If you try to enter 12.345 into the field, an error message would display, as this exceeds the maximum number of digits and decimal places allowed. On the other hand, if you specify a float with a precision of 5 and a scale of 3, the field would let you enter 12.345.
Data types and their possible precision and scale values are listed in the following table. Use this table to help you choose data type, precision, and scale:
|Data type||Precision (field length)||Scale (decimal places)|
1–5 (Oracle, SQL Server, PostgreSQL, Netezza); 5 (DB2)
6–10 (Oracle and PostgreSQL); 6–9 (DB2, Netezza, and SQL Server)
*By default in ArcGIS Pro, 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. Therefore, 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 for you to specify a precision for short integer columns created in ArcGIS Pro on any database except Oracle. There is no reason to specify a precision for long integer columns created in ArcGIS Pro on SQL Server or PostgreSQL databases.
The following provides examples of number ranges and how you could store them in a database or enterprise geodatabase:
|Range||Data type||Precision (field length)||Scale (decimal places)|
0 to 99
-99 to 99*
0 to 32,767*
32,768 to 99,999
0.001 to 0.999
1,000.00 to 9,999.99
-123,456.78 to 0*
0 to 1,234.56789
*Negative numbers require additional precision to store the negative sign.
Computers can only store a limited number of digits, depending on the storage space being allocated. Fields of data type double in databases and geodatabases can precisely store numbers that contain up to 15 digits only, 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 enter the 20-digit number 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.
Floats in file geodatabases can precisely store numbers that contain up to 6 digits only. For example, you could not store the number 123,456.7 precisely in a float field, because this number contains more than six digits. You can enter the number into a float field in a file geodatabase, but it will be rounded to 123,457, a number containing the permissible 6 digits. If you need to store this number precisely, you could store it in a double field. Float fields in enterprise geodatabases and databases do not let you enter more digits than the precision for the field, so no rounding takes place.
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. A textual description would be coded with a numeric value. For example, you might 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 your coded values in a coded value domain in the geodatabase and associate the domain with the integer field storing your codes, the geodatabase will display the textual description when the table is viewed in ArcGIS Pro.
The characters used for text vary by language. To allow text to more easily convert between languages, ArcGIS uses Unicode to encode characters.
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 enter date fields in the table through ArcGIS, they are converted to this format.
A BLOB is data stored as a long sequence of binary numbers. ArcGIS stores annotation and dimensions as BLOBs, and items such as images, multimedia, or bits of code can be stored in this type of field. You need to use a custom loader or viewer or a third-party application to load items into a BLOB field or view the contents of a BLOB field.
The ObjectID 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 will usually see the ObjectID field listed under the aliases of OID or ObjectID for tables and FID for layers. Key functions, such as scrolling and displaying selection sets, depend on the presence of this field.
It should be noted that most ArcGIS Pro functionality, such as using the Identify tool, requires the ObjectID to be unique. Therefore, caution should be used when working directly with the database outside of ArcGIS so that ObjectIDs are not duplicated. For example, when creating views with a one-to-many relationship, there is the possibility that ObjectIDs will be duplicated. This will cause inconsistent behavior in ArcGIS Pro functionality.
When you add a database table to the Map, an object identifier is needed. If ArcGIS cannot find a not null, integer field to use as an object identifier, you will be prompted to choose a field to be used as the object identifier. See Choose a unique identifier field for a query layer for more information.
Global ID and 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. This is how features are tracked in one-way and two-way geodatabase replication. Developers can use them in relationships or in any application requiring globally unique identifiers. 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 by using the Add Global IDs geoprocessing tool. The geodatabase will then maintain these values automatically. You can create the GUID field as well, but you must maintain its values.
Databases with a native GUID data type, such as Microsoft SQL Server, store global ID and GUID values as 16 bytes. Databases without a native GUID data type store them as 38 bytes.
Some notes on global IDs
- GUID fields can be added to geodatabase datasets using fields view, or the New Field command in the table window.
- You can add Global IDs for stand-alone feature classes, tables, and attributed relationship classes in geodatabases. It cannot be executed on individual datasets in a feature dataset; it can only be run on the entire feature dataset. It also cannot be run on tables in a database.
- If a Global ID column already exists, the tool leaves the old column; it doesn't drop and add a new Global ID column.
- If you add a feature class to a feature dataset in a geodatabase and want to add a Global ID column to it, you need to run the Add Global IDs tool on the feature dataset. This will add a Global ID column to the new feature class and any feature classes that don't already have a Global ID column. Feature classes already having a Global ID column will remain unchanged.
- Copying and pasting, data extraction, and XML workspace exporting and importing preserve Global ID values in the output geodatabase. Other data exporting and importing methods do not preserve these values.
Fields of type raster
Unlike a hyperlink that simply links a feature's field to an image, a field type raster can actually store the raster data within or alongside the geodatabase. To learn more, see Adding raster datasets as attributes in a feature class.
In ArcGIS, the geometry data type indicates the type of geometry—point, line, polygon, multipoint, or multipatch—the table stores. The field stored as geometry type is called 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 will have an ArcGIS data type of Geometry.
In the Geometry Type property of the feature class properties dialog, you will see the geometry type listed as Polygon.
If you had created a feature class with a different feature type—line, point, multipoint, multipatch, dimension, or annotation—the geometry type for the SHAPE field would change accordingly—to line, point, multipoint, multipatch, or polygon for dimension and annotation.
When you create a geometry field in a feature class in a database or enterprise geodatabase, there is an additional data type to consider: the database data type. How the value of the SHAPE field is stored in the DBMS depends on the geometry storage type used by the DBMS. When you create a feature class in a geodatabase, the geometry storage type used is determined by the GEOMETRY_STORAGE parameter setting of the configuration keyword you specify. When you 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 dialog.