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), and globally unique identifiers (GUIDs). Choosing the correct data type allows you to correctly store the data and facilitates your analysis, data management, and business needs.
The data types described in this topic include those available when creating a feature class or table with ArcGIS. If you store your data in a database or a geodatabase in a database, ArcGIS data types and the data types of the database management system (DBMS) may not match directly. The types are matched to the closest database data type available. This process is referred to as data type mapping. In this process, it is possible that the values will be stored in the database 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. To learn more about the data type mapping process, see DBMS data types supported in ArcGIS.
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)
When choosing the data type, consider the need for whole numbers versus fractional numbers. If you only 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 with decimal places, such as 0.23 or 1234.5678, specify a float or a double.
When choosing between short integer and long integer or between float and double, choose the data type that takes up the least storage space. This not only minimizes the amount of storage required but 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 only 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.
The table below lists data types, their ranges, and storage requirements. The ranges listed are for file and mobile geodatabases. Ranges differ slightly in databases and enterprise geodatabases.
|Data type||Storable range||Size (bytes)||Application|
-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 add numeric fields to a table or feature class in a file or mobile geodatabase, you need only specify the data type. 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.
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 will display, 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 enter 12.345.
Data types and the precision and scale values you can specify when you add a field in fields view are listed below. Use this information to help you choose data type, precision, and scale.
|Data type||Precision (field length)||Scale (decimal places)|
1–5 (Oracle); 5 (IBM Db2, Microsoft SQL Server, and PostgreSQL
6–10 (Oracle); 6–9 (Db2), 10 (SQL Server and PostgreSQL)
*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. 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 Pro 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:
|Range||Data type||Precision (field length)||Scale (decimal places)|
0 to 99
-99 to 99*
-32,768 to 32,767*
-99,999 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.
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 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 six digits. To store this number precisely, you can store it in a double field. Float fields in enterprise geodatabases and databases do not allow you to enter more digits than the precision for the field, so no rounding occurs.
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 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.
When you create a table in ArcGIS, a unique, nonnullable integer field 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 Pro 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 Pro 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 Choose a unique identifier field for a query layer for more information.
ArcGIS does not maintain the values in these database fields, and it is not guaranteed that all values in these fields are unique.
Global ID and GUID data types store registry-style strings consisting of 36 characters enclosed in curly brackets. 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 table row 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 the GUID field as well, but you must maintain its values. Copy and paste preserves Global IDs of a table or feature class, thus it is possible to have nonunique Global IDs in a database.
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; they can only be applied on the entire feature dataset.
- Global IDs cannot be added to tables in a database.
- If there is an existing global ID column, the 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 need to run the Add Global IDs tool on the feature dataset. This adds a global ID column to the new feature class and any feature classes that don't have an existing global ID column. Feature classes 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. Other data exporting and importing methods do not preserve these values.
Fields of type raster
Unlike a hyperlink that only links a feature's field to an image, a field type raster can store the raster data in or alongside the geodatabase. 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.
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.
When you create a geometry field in a feature class in a database or enterprise geodatabase, you also need 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 an enterprise 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 tool.