Fields are the components that provide structure for a table. You can't have a table without fields. For instance, you can create an empty table that has fields defined but no rows (records).
In databases, fields are used to maintain relationships between tables. This is done by creating matching fields in two or more tables. For example, if you stored a table named toy_store in a database and you also stored a staff table to track the employees in each store, you would create a common field between the two tables that would be populated with, for instance, a store ID. The store ID value for a specific toy store would be the same in both tables.
Below, a STORE_ID field has been added to the toy_store table:
The toy_store table is linked to an employee table by the store ID. The table below shows three employees of The Play House:
Certain fields are also used to maintain relationships between tables and their attribute indexes.
Fields in a table store the same category of data in the same data type. For example, if you have a CUSTOMER_NAME field in a table of customers, the entries for this field are all customer names and are stored as text. You wouldn't mix the entries; that is, you wouldn't put a customer name in this field for one record and a product name in the same field for another record.
When you create a table or add fields to an existing table, you define the data type used to store the data in each field. In some cases, you also specify the length of the field.
Field names
Field names are the names you give to the columns in a table. The names should indicate what data is contained in each column. For example, when you create a feature class in ArcGIS, the table is prepopulated with an ObjectID field and a shape field. The ObjectID field contains the unique ID number for each object in the feature class. The shape field defines the type of shape stored in the feature class: point, line, polygon, multipoint, or multipatch.
You can also use set phrases to indicate the type of column. For example, if you create a separate unique ID on a table that you will use for indexing purposes, you might name the field ID_UK, with UK indicating this is a unique key.
Field names in the same table must be unique; for instance, you can't have two fields with the name ObjectID. Field names must also start with a letter and not contain spaces or reserved words. See File geodatabase size and name limits, Mobile geodatabase size and name limits, or Database and cloud data warehouse data in ArcGIS for more information about database-specific limitations.
Certain field names appear in ArcGIS with their fully qualified names for tables stored in an enterprise geodatabase. For example, if you create or import a polygon feature class that contains a field named Area, the database, schema, and table name are appended to it. This is the name you see in the attribute table of the feature class. That means for a polygon feature class named archsites, stored in the prof schema of the museum database, the Area field would be MUSEUM.PROF.ARCHSITES.AREA.
The following list contains all the field names that are fully qualified in an enterprise geodatabase:
- FID
- AREA
- LEN
- POINTS
- NUMOFPTS
- ENTITY
- EMINX
- EMINY
- EMAXX
- EMAXY
- EMINZ
- EMAXZ
- MIN_MEASURE
- MAX_MEASURE
For cases such as this, you might consider using a different field name or a field alias.
Field name length
In ArcGIS Pro, the maximum length for a field name is 128 characters for most geodatabase formats. However, the number of characters that can be used depends on the limits imposed by the underlying database management system (DBMS) and the character encoding used. To prevent a field name from being truncated, ensure the field name length is within the maximum character and byte limits outlined in the table below.
Field name length limits can be based on either the number of characters or the number of bytes.
- Characters—These are the letters, numbers, and symbols you type. For example, "A", "1", and "!" are all characters. The number of bytes required to store a character can vary based on the encoding used.
- Bytes—These are units of digital information consisting of eight bits. Different characters can take up different numbers of bytes. For example, the letter "A" might take up 1 byte, but a character with a diacritic, such as "é", might take up 2 bytes.
Different databases and geodatabase types have different limits about how long field names can be. For example, when working with data in a file geodatabase or memory workspace, the maximum field length is 128 characters. For mobile geodatabases, and enterprise geodatabases, ArcGIS Pro allows for a maximum of either 128 characters or 256 bytes, depending on which limit you reach first. Some databases, like PostgreSQL and Oracle, have stricter byte limits, which can result in truncated or shorter permissible field names.
Note:
This difference in supported field name lengths can lead to field names being truncated when you copy data between geodatabases. This applies to workflows that move data directly between geodatabases in ArcGIS Pro—such as exporting and importing or copying and pasting tables and feature classes—as well as to geodatabase replication, publishing feature layers that copy the data to ArcGIS Enterprise, and using distributed collaboration in ArcGIS Enterprise.
Character encoding determines how each character is represented in bytes. The following are common character encodings:
- ASCII—Uses 1 byte per character and is primarily used for English text, including letters, digits, punctuation marks, and control characters.
- UTF-8—Uses between 1 and 4 bytes per character. It is widely used for web pages and emails and can represent any character in the Unicode standard while being backward-compatible with ASCII.
- UTF-16—Uses 2 or 4 bytes per character and is commonly used in many operating systems and environments. It can represent all Unicode characters and is efficient for texts with many non-ASCII characters.
- ISO-8859-1—Uses 1 byte per character and is used for Western European languages, covering most characters used in these languages.
The following table outlines the maximum character and byte limits that ArcGIS can create for field name lengths in different geodatabase types:
| Geodatabase type | Maximum field length | Measurement unit | Character limit |
|---|---|---|---|
File geodatabase and memory workspace | 128 characters | Characters | 128 characters, regardless of the byte size of each character. |
Mobile and enterprise geodatabases | 128 characters with 256-byte maximum* | Bytes | Vary based on character encoding. (for example, 128 UTF-16 characters) |
* If your database allows fewer bytes or characters than what ArcGIS Pro allows, you are limited to the number of characters allowed by the database. See File geodatabase size and name limits, Mobile geodatabase size and name limits, or Database and cloud data warehouse data in ArcGIS for more information about database-specific limitations.
If your field name uses characters that use multiple bytes, you might hit the byte limit before reaching the character limit. To illustrate these concepts, consider the following examples:
Example 1: A field name with 100 characters, where each character uses 3 bytes (UTF-8 encoding).
- Total bytes = 100 characters * 3 bytes/character = 300 bytes
- This exceeds the 256-byte limit and would be truncated.
Example 2: A field name with 128 characters, where each character uses 2 bytes (UTF-16 encoding).
- Total bytes = 128 characters * 2 bytes/character = 256 bytes
- This meets the 256-byte limit and would be accepted.
Tip:
- Consult DBMS documentation—Always check the specific object name limitations of your DBMS.
- Use clear and concise names—Aim for field names that are descriptive yet within the character and byte limits.
- Use a field alias—For tables registered with the geodatabase, you can use a field alias to give the field a more descriptive name or a name that uses symbols or spaces.
- Test across databases—If working with multiple databases, test field names to ensure they meet the limits of each DBMS.
By understanding these limitations and how they apply to different types of geodatabases, you can effectively manage field names in ArcGIS Pro and avoid issues related to field name truncation.
Rename fields
You can rename fields in a table or feature class in the fields view.
To rename a field, right-click the feature class or table in the Catalog pane and click Data Design > Fields. This opens the fields view, where you can modify field properties. Double-click the field name cell that you want to change and type a new field name. To commit your changes, click the Save button 
in the Changes group on the Fields tab.
The following fields cannot be renamed:
- ObjectID and global ID fields
- Any shape-related field: Shape, shape length, shape area
- The enabled, ancillary role, or network weight fields of a network feature class
- Representation fields
- Fields in a feature class participating in a network dataset, terrain, or parcel fabric
- Fields used for editor tracking
- Relationship class primary key and foreign key fields
- The subtype field
- Raster fields
Field name rules and limitations
The following table lists supported field name character rules:
| Character | Start of name | Other position | In alias |
|---|---|---|---|
Letters (A–Z) |  | | |
Underscore ( _ ) | | | |
Digits (0–9) | | | |
Spaces | | ||
Symbols (other than underscore) | | ||
Superscript letters and digits | | ||
Subscript letters and digits | |
Additional field name rules and limitations are as follows:
- Field names cannot contain reserved words, such as all or result.
Consult your DBMS documentation for additional reserved words.
- The length of field (column) names depends on the underlying database.
See File geodatabase size and name limits, Mobile geodatabase size and name limits, or Database and cloud data warehouse data in ArcGIS for more information about database-specific limitations.
Note:
To learn more, see the table summarizing feature class and table name rules and limitations in Define feature class properties.
Field aliases
Field aliases allow you to assign an alternate name for a field. You typically use field names that are as short as possible to convey what data is stored in that field. You cannot use spaces or special characters in the field name, and certain fields appear in the table with their fully qualified names. In these cases, you can use a field alias to give the field a more descriptive name. For example, if you have a field named ST_SUFX that stores the type of street, which is indicated by the suffix used on the street name, you can give this field an alias of Street name suffix.
Learn how to set a field alias
Tip:
Geoprocessing methods allow you to validate table and field names. See Validating table and field names in Python for more information.
Use domains to control field values
Attribute domains are rules that indicate valid values for a field in a table in a geodatabase. They enforce data integrity by restricting the data values a user can add to a specific field.
You can apply attribute domains to fields only if there was a definable set or range of specific values possible for that field. For example, a field that stores the answer to the survey question What is your favorite food? is difficult to apply a domain to, since there are a large number of responses that can be given. However, a field storing data on eye color can have an attribute domain assigned to it, because there are only a few possible valid values.
- Black
- Brown
- Blue
- Green
- Hazel
- Gray
- Violet
Using an attribute domain for a field storing eye color data ensures consistency of the values. If data collectors are allowed to type any color in a text field for eye color, you might end up with any of the following for blue eyes:
- Azure
- Navy
- Sky blue
- Cobalt
- Aquamarine
Attribute domains also prevent misspellings or typographical errors. Even if data collectors know to only use the term blue for blue eyes, they might misspell the word (bleu) or mistakenly type the wrong letter when typing the word (vlue) in a text field.
Types of attribute domains
There are two types of attribute domains you can use to restrict field values: coded value domain and range domain.
Coded value domain
A coded value domain uses codes to define a set of allowed values for a field that stores discrete data. You can use a coded value domain for most field data types.
Note:
- Domains on Date, Date only, and Time only field types support only whole second-based precision.
- Domains on Global ID, Object ID, Blob, Raster, and Timestamp offset fields are not supported with coded value and range.
For the eye color field, you could create a coded domain using one of the following example code sets:
- Example 1
- Blk = Black
- Brn = Brown
- Blu = Blue
- Grn = Green
- Hzl = Hazel
- Gra = Gray
- Vlt = Violet
- Example 2
- 1 = Black
- 2 = Brown
- 3 = Blue
- 4 = Green
- 5 = Hazel
- 6 = Gray
- 7 = Violet
Range domain
A range domain defines a range of allowed numeric values for a field.
The field must be a numeric or date data type to use a range domain. You can apply a range domain to short integer, long integer, big integer, float, double, date, date only, and time only field types. An example of a field to which you might apply a range domain is one that stores data on birth weights for single live births of western lowland gorillas in zoos. The range would run from the lowest weight (1 kg) to the highest (2.5 kg).
Use subtypes
Subtypes are classifications within a feature class or table in a geodatabase. They allow you to logically group features based on a unique characteristic or behavior of the data. This characteristic or behavior is represented by the values of one field in the table. For example, for a table of hydrology, you could have subtypes for different types of waterways, such as creeks, streams, channels, canals, and rivers. For each of these subtypes, you could apply different topology rules, connectivity rules, default values, and relationship rules.
Using subtypes to store groups of related features can improve query performance. If you stored the different types of data in separate feature classes instead of using subtypes, you would have a greater number of feature classes in the database, and it could take longer to search.
The following rules apply when using subtypes:
- Only one field in a table or feature class can have subtypes applied to it.
- The field on which you base the subtype must be a long or short integer field.
- You can apply different topology and relationship rules to different subtypes.
- You can apply different attributes or coded domains to other fields in the table based on subtypes.
Note:
You apply the domain to a field for a specific subtype.