Access - Campos fecha en SQL

Estoy desarrollando una aplicación con Access 2010 + SQL Server Express 2014. El tema es que de algunas tablas, los campos de tipo fecha en SQL, la tabla vinculada en Access los interpreta como texto. Esto me acarrea muchos problemas al tratar de compararlos/procesarlos desde Access. Alguien que da una mano???

Un texto que representa a una fecha "27-ene-2022"

Una función integrada ==> CDate()

Su aplicación:
Cdate("27-ene-2022")

Un resultado
==> una valor de tipo DATE con el que Access puede trabajar

Uso esa función para mostrar correctamente la fecha, el tema es cuando quiero hacer una comparación. Por ejemplo: Set xx = Base.openrecordset("select * Fom Creditos where FechaOtorgamiento = " + trim(Date))... Donde FechaOtorgamiento dice Date en SQL pero en Access dice "Texto". Allí tengo problemas.

Si ese dato se comporta de igual manera en todos sus registros (algo que se da por supuesto dado que es el tipo de dato del campo) y dado que se conoce (o se deberían conocer que campos no son 'bien trasladados') ¿Qué problema hay en aplicar el tratamiento al campo de la tabla en la misma SQL?.

Se parte del supuesto de que la SQL se ejecutara en el entorno Access.

Y si el entorno es Access hay pequeños detalles que pueden complicarle la vida al motor de Access al momento de analizar la sintaxis en tiempo de ejecución:

La SQL:
Set xx = Base.openrecordset("select * Fom Creditos where FechaOtorgamiento = " + trim(Date))...

.- el signo (+) utilizado como concatenador y asumido por compatibilidad en Access, tiene algún que otro efecto colateral no deseado, su comportamiento es diferente al del signo (&), concatenador utilizado en Access por defecto.

.- No veo cual es la causa para aplicarle a un dato (supuestamente una fecha, básicamente un numero) la función 'TRIM' que es de aplicación en las cadenas de texto para eliminar espacios al principio y final.

Si es una fecha (esto es si es un dato de tipo DATE) ¿Qué se logra con TRIM? .... posiblemente esto cause el problema de la indefinición del tipo de datos de ambos operandos.

En definitiva, que tipo de dato es:
FechaOtorgamiento
y también que tipo de dato es
Date

Ambos deberían ser del mismo tipo (real o convertido) para poder ser comparados de forma correcta:

Campo texto a fecha ==> ... where FechaOtorgamiento = ... ==> ... where CDate(FechaOtorgamiento) = ....

Respetando el tipo de dato como Fecha Access ==> .. = " + trim(Date))... ==> = " & Date() ...


Es complicado (con los datos aportados y probablemente inventados para el ejemplo) aportar una solución en la el problema puede tener diferentes motivos (sea la sintaxis, tipo de datos o tratamiento de los mismos)

Antes que nada, gracias por la pronta respuesta. Paso a comentarte: a la hora de escribir sintaxis SQL, nunca tuve problemas con usar el signo "+" en vez de "&". Digamos que costumbre. En cuanto el Trim, lo uso siempre por que no tan solo quita los espacios en blanco al comienzo y al final sino que convierte cualquier cosa a string. Teniendo en cuenta que Access me muestra la fecha como un texto con el formato yyyy-mm-dd, resolví el tema haciendo la siguiente función:


Luego el filtro queda así:


Anda bien, solo que temo que no use el índice que en SQL le puse a este atributo.

Si es el único método que conoces (o dominas), mientras te funcione o no llegues a un muro insalvable .....

Pero yo 'hablaría' el ruso en Moscú, el castellano en Madrid y el chino en Pequín si desease transmitir bien los conceptos en lugar de esa extraña mescolanza o el intento de generar 'mi propio idioma'.

En fin, incluso entre los 'castellanos parlantes' según su ubicación geográfica hay (para la misma palabra) diferentes significados por ejemplo: 'coger' ..... pues no es lo mismo que te 'cojan' en Madrid a que lo hagan en algunos países sudamericanos.

Espero que quede claro que esa comparación no esta expuesta mas que para señalar las diferencias (se que en algunos países sudamericanos esa expresión les molesta, pero quienes le dieron 'otro sentido' fueron ellos).