Seleccionar por atributos en función del rango de comodines de SQL

Quiero seleccionar todos los registros de una tabla de geodatabase donde la cadena comienza con una letra, así que intenté

SELECT *
FROM tbl_names
WHERE "name" LIKE '[A-Z]%'

Esto no devolvió registros. Después de algunas búsquedas, descubrí que esta es la sintaxis de SQL Server. Sin embargo, no pensé que esto sería un problema, por lo que sé, todas las versiones de soporte de SQL %. Después de revisar el archivo de ayuda para crear una expresión de consulta , vi que la sintaxis correcta es

SELECT *
FROM tbl_names
WHERE "name" >= 'A'

Como los nombres son todos cadenas, mi primer instinto fue intentarlo LIKE. ¿Por qué se >=usa el operador en lugar de LIKE? ¿Los rangos de comodines no son compatibles con ArcMap?

Los comodines en general son compatibles con ArcMap. Aquí hay un extracto de la ayuda que obtienes mientras haces un 'Seleccionar por atributos':

Use el operador LIKE (en lugar del operador =) para construir una búsqueda de cadena parcial. Por ejemplo, esta expresión seleccionaría Mississippi y Missouri entre los nombres de estado de EE. UU .:

"STATE_NAME" LIKE 'Miss%'

Puede usar operadores mayores que (>), menores que (<), mayores o iguales (> =), menores o iguales (<=) y ENTRE para seleccionar valores de cadena según el orden de clasificación. Por ejemplo, esta expresión seleccionará todas las ciudades en una cobertura con nombres que comienzan con las letras M a Z:

"CITY_NAME" >= 'M' El <>operador no igual ( ) también se puede utilizar al consultar cadenas.

Caracteres comodín Un carácter comodín es un símbolo especial que representa uno o más caracteres.

Para cualquier dato basado en archivos, '%' significa que cualquier cosa es aceptable en su lugar: un carácter, cien caracteres o ningún carácter. Alternativamente, si desea buscar con un comodín que represente un carácter, use '_'.

Por ejemplo, esta expresión seleccionaría cualquier nombre que comience con las letras Cath, como Cathy, Catherine y Catherine Smith:

"NAME" LIKE 'Cath%'

Pero esta expresión encontraría a Catherine Smith y Katherine Smith:

"OWNER_NAME" LIKE '_atherine smith' Los comodines que utiliza para consultar geodatabases personales son '*' para cualquier número de caracteres y '?' para un personaje

Los caracteres comodín aparecen como botones en el cuadro de diálogo de consulta. Puede hacer clic en el botón para ingresar el comodín en la expresión que está creando. Solo se muestran los caracteres comodín que son apropiados para el origen de datos de la capa o tabla que está consultando.

Si usa un carácter comodín en una cadena con el operador =, el carácter se trata como parte de la cadena, no como un comodín.

Con una tabla unida, use comodines apropiados para el lado de la unión que está consultando. Si la consulta solo se aplica a los campos de la tabla de destino (la tabla del lado izquierdo), utilice los comodines de la tabla de destino. Si la consulta solo se aplica a los campos de la tabla de unión (la tabla del lado derecho), use los comodines de la tabla de unión. Si la consulta involucra campos de ambos lados de la unión, use los comodines '%' y '_'.

Por ejemplo, si une un archivo dbf (la tabla de unión) a una clase de entidad GDB personal (la tabla de destino):

1. Use * para consultas que solo involucren campos GDB personales.

2. Use% para consultas que solo involucran columnas dbf.

3. Use% para consultas que involucran columnas de ambos lados de la tabla.

De acuerdo con esto: creo que los rangos no son compatibles, en su lugar, debe usar> y <, tal como lo hizo.

Sí, puede usar comodines en las declaraciones LIKE. Nunca he usado rangos a través de ArcMap, pero está usando la sintaxis correcta desde el punto de vista de SQL Server.

Sin embargo, una advertencia rápida si va a utilizar el operador '> ='. El resultado de esto diferirá según la colación establecida. Esto puede alterar la forma en que se realiza la clasificación de los datos, por ejemplo, si distingue entre mayúsculas y minúsculas o no. Entonces, en algunos casos, puede encontrar que su consulta solo devuelve valores que comienzan con letras mayúsculas y, a veces, mayúsculas y minúsculas.

Ver http://sqlblog.com/blogs/louis_davidson/archive/2007/05/20/sorting-and-case-sensitive-collations.aspx .

Además, si solo está interesado en el primer carácter del campo, puede usar

WHERE SUBSTRING("name", 1, 1) >= 'A'

más bien que

WHERE "name" >= 'A'

Esto podría tener beneficios de rendimiento si nada más.