SQL referenceFieldsStringsNumbersDatesSubqueriesOperatorsFunctons

This topic is a reference to the SQL (Structured Query Language) WHERE clause features and functions in ArcGIS and applies to file, personal, and ArcSDE geodatabases, as well as file-based data sources such as shapefiles and coverages. It shows you how SQL syntax differs depending on the data source. Migrating to the file geodatabase contains a concise summary of the syntax differences between file and personal geodatabases. File geodatabases and other file-based data sources support the WHERE clause features and functions listed in this topic only. Personal and ArcSDE geodatabases support many additional features and functions not mentioned in this topic. For information on those, refer to your database management system (DBMS) documentation. FieldsTo specify a field in a SQL expression, you only need to provide a delimiter if the field name would otherwise be ambiguous, such as if it were the same as a SQL reserved keyword. Since there are many reserved keywords and new ones can be added in subsequent releases, a good practice is to always enclose a field name with a delimiter. If you're querying any file-based data such as a file geodatabase, ArcSDE geodatabase data, or data in an ArcIMS feature class or ArcIMS image service sublayer, you can enclose field names in double quotes: "AREA"

If you're querying personal geodatabase data, you can enclose fields in square brackets: [AREA]

The exception is personal geodatabase raster datasets, where you should enclose field names in double quotes. StringsStrings must always be enclosed in single quotes in queries. For example: STATE_NAME = 'California'

Case sensitivity depends on the data source of the layer or table you are querying. Strings are case sensitive in expressions for any file-based data source and multiuser geodatabase feature classes and tables. For these feature classes and tables, you can use the UPPER or LOWER function to set the case for a selection. For example: UPPER("STATE_NAME") = 'RHODE ISLAND'

Strings are case insensitive for personal geodatabase feature classes and tables. If needed, you can use the UCASE and LCASE functions that are equivalent to UPPER or LOWER. The wildcards you use to conduct a partial string search also depends on the data source you are querying. For example, in a file-based or multiuser geodatabase data source, this expression would select Mississippi and Missouri among USA state names: "STATE_NAME" LIKE 'Miss%' % means that anything is acceptable in its place: one character, a hundred characters, or no character. The wildcards you use to query personal geodatabases are * for any number of characters and ? for one character. String functions can be used to format strings. For instance, the LEFT function would return a certain number of characters starting on the left of the string. In this example, the query would return all the states starting with the letter A: LEFT("STATE_NAME",1) = 'A'

Refer to the documentation of the database for a list of supported functions. NumbersThe decimal point (.) is always used as the decimal delimiter, regardless of your regional settings. The comma cannot be used as a decimal or thousands delimiter in an expression. You can query numbers using the equal (=), not equal (), greater than (>), less than (=), less than or equal (= 5000

Numeric functions can be used to format numbers. For instance, the ROUND function would round a number to a given number of decimals in a file geodatabase: ROUND("SQKM",0) = 500

Refer to the documentation of the database for a list of supported numeric functions. DatesGeneral rules Most of the data sources, except coverages and shapefiles, store dates in a date-time field supporting the storage of both date and time information. Therefore, most of the query syntax listed below contains a reference to the time. In some cases, the time part of the query may be safely omitted when the field is known to contain only dates; in other cases, it needs to be stated or the query will return a syntax error. This is mentioned for each data source below. The main purpose of the ArcMap date format is to store dates, not times. It is possible to store only a time in the field when the underlying database actually uses a date-time field, but it is not recommended. Querying against time is a bit awkward; for instance, 12:30:05 p.m. will be stored as '1899-12-30 12:30:05'. NOTE: Dates are stored in the underlying database as a reference to December 30, 1899, at 00:00:00. This is valid for all the data sources listed here.The purpose of this section is only to help you query against dates, not time values. When a non-null time is stored with the dates (for instance, January 12, 1999, 04:00:00), querying against the date only will not return the record because when you pass only a date to a date-time field, it will fill the time with zeros and retrieve only the records where the time is 12:00:00 a.m. The attribute table shows date and time in a user-friendly format, depending on your regional settings, rather than the underlying database's format. This is fine most of the time but also has a few drawbacks: The string shown in the SQL query may only slightly resemble the value shown in the table, especially when time is involved. For instance, a time entered as 00:00:15 will show as 12:00:15 a.m. in the attribute table, with the United States as your regional settings, and the query syntax would be Datefield= '1899-12-30 00:00:15'. The attribute table does not know what the underlying data source is until you save your edits. It will first try to format the value entered to fit its own format, then upon saving edits, it will try to tweak the resulting value to fit into the database. Because of this, you can enter a time in a shapefile but you will find that it is dropped when you save your edits. The field will then contain a value '1899-12-30' that will show as 12:00:00 a.m. or something equivalent depending on your regional settings. Syntax by data source ArcSDE-Informix Datefield = 'yyyy-mm-dd hh:mm:ss'

The hh:mm:ss part of the query cannot be omitted even if it's equal to 00:00:00. ArcSDE-Oracle Datefield = date 'yyyy-mm-dd'

Keep in mind this will not return records where the time is not null. An alternative format for querying dates in Oracle is Datefield = TO_DATE('yyyy-mm-dd hh:mm:ss','YYYY-MM-DD HH24:MI:SS')

The second parameters 'YYYY-MM-DD HH24:MI:SS' describe the format used for querying. An actual query would look like Datefield = TO_DATE('2003-01-08 14:35:00','YYYY-MM-DD HH24:MI:SS')

You can use a shorter version as in TO_DATE('2003-11-18','YYYY-MM-DD')

Again, this will not return records where the time is not null. ArcSDE-SQL Server Datefield = 'yyyy-mm-dd hh:mm:ss'

The hh:mm:ss part of the query can be omitted when the time is not set in the records. An alternative format is Datefield = 'mm/dd/yyyy'

ArcSDE-DB2 Datefield = TO_DATE('yyyy-mm-dd hh:mm:ss','YYYY-MM-DD HH24:MI:SS')

The hh:mm:ss part of the query cannot be omitted even if the time is equal to 00:00:00. ArcSDE-PostgreSQL Datefield = TIMESTAMP 'YYYY-MM-DD HH24:MI:SS'Datefield = TIMESTAMP 'YYYY-MM-DD'

You must specify the full timestamp when using "equal to" queries, else no records will be returned. You could successfully query with the following statements if the table you query contains date records with these exact timestamps, 2007-05-29 00:00:00 or 2007-05-29 12:14:25: select * from table where date = '2007-05-29 00:00:00';

or select * from table where date = '2007-05-29 12:14:25';

If you use other operators, such as >,