Fechas y horas en Access

1. Índice.
2. Qué es una fecha.
3. Qué tipos de campo de fecha hay.
4. 5 de enero o 1 de mayo.
5. Operar con fechas.
6. Bibliografía.

Qué tipos de campo de fecha hay

Al contrario que en otros sistemas de bases de datos, en Access sólo disponemos de un tipo de campo Fecha y Hora. Esto significa que si en un campo de tipo Fecha y Hora, sólo queremos guardar la fecha o la hora, tendremos que usar reglas de validación o máscaras de entrada para evitar que el usuario nos guarde información no deseada.

Para evitar guardar información no deseada, no nos sirve la propiedad Formato de ese campo, ya que como indica Access:

El diseño de la presentación para el campo. Seleccione un formato predefinido o introduzca un formato personalizado. Presione F1 para obtener ayuda acerca de formatos.

Es decir, esta propiedad sólo sirve para indicar cómo queremos ver lo que hemos guardado, no lo que queremos guardar.

Podemos hacer una pequeña prueba para verificar esto:

1. Crea una nueva tabla en vista Diseño.
2. Crea un nuevo campo, de nombre SoloFecha, y tipo Fecha y Hora.
3. A su propiedad Formato, dale el valor Fecha corta.
4. Guarda la tabla con el nombre TablaPruebas, y prueba a introducir valores de fechas válidos.

Por ejemplo, yo he insertado los siguientes valores:

• 01/01/2008
• 31/12/2007
• 15:00
• 02/01/2008 20:00

Como todos los valores son fechas y horas válidos, Access permite guardarlos, aunque luego nos los muestra según el formato indicado en el diseño del campo:

• 01/01/2008
• 31/12/2007
• 30/12/1899
• 02/01/2008

Y si volvemos al diseño de la tabla, y quitamos el formato del campo, volveremos a ver los datos tal y como los habíamos introducido.

Para evitar esto, podemos usar la propiedad Máscara de entrada para especificar una máscara que sólo permita introducir los datos tal y como deseamos. Siguiendo el ejemplo, la máscara puede ser 00/00/0000, que nos evita el poder introducir una hora, por ejemplo.

Pero la propiedad Máscara de entrada tiene un problema: que no nos filtra los valores. Por ejemplo, si creamos la siguiente consulta en vista SQL:

Y la ejecutamos, nos insertará una hora en el campo de la tabla, pero sin la parte de fecha válida.

Para evitarlo, podemos usar las reglas de validación del campo. Si quitamos la máscara, y creamos la siguiente regla de validación:

Vamos a especificar que sólo vamos a admitir números sin decimales. Con Fix() recogemos la parte entera del decimal, y al usar el igual, indicamos que el valor introducido debe ser igual al valor devuelto por Fix(). Y Fix() nos funciona perfectamente, porque como hemos indicado anteriormente, una fecha se almacena como un número con decimales.

Podemos agregar más criterios. Por ejemplo, podemos querer que se introduzcan valores mayores que cero, que la regla anterior sí nos lo permitirá. Sólo necesitamos indicar que el número debe ser mayor que uno, por ejemplo:

Si intentamos ejecutar la consulta anterior, Access nos avisará de que no puede anexar debido a infracciones en las reglas de validación. Aunque nos da la opción de intentar agregar los registros, ya tenemos un aviso de que tal vez estemos haciendo algo mal.

¿Y si sólo queremos tener horas? En este caso, la regla de validación tiene que indicar que sólo queremos las horas, minutos y segundos. Y como ya sabemos que estos datos se almacenan en la parte decimal del número, tan sólo hay que indicar que el valor debe estar entre cero (medianoche) y uno (medianoche del día siguiente):

¿Y si necesitamos usar código VBA para ejecutar las consultas? En este caso, el resultado va a depender de qué instrucciones seleccionemos:

• Si usamos la instrucción DoCmd.RunSql, el resultado va a ser el mismo que si ejecutamos una consulta guardada en la base de datos: Access nos avisará que hay registros que rompen las reglas de validación, pero nos permitirá guardarlos.
• En cambio, si usamos CurrentDb.Execute, el resultado es completamente distinto: no aparece ningún mensaje, pero los registros tampoco se almacenan en la tabla.
• Si usamos la librería DAO y su objeto QueryDef, podemos crear una consulta de inserción y ejecutarla. Después, en su propiedad RecordsAffected obtendremos el número de registros que se han agregado a la tabla. Si este número es menor que el número de registros que íbamos a insertar o actualizar, podemos deducir que alguno de ellos no ha cumplido con las reglas de validación que hemos creado en el diseño de la tabla. Y digo esto porque este objeto no nos va a dar ninguna información de que algún registro no cumple con las reglas de validación que hemos creado.
• Otro objeto de la librería DAO que podemos usar para insertar registros es Recordset, mediante sus métodos AddNew y Update. Este objeto sí que va a informarnos de que estamos rompiendo las reglas de validación, pero mediante un error, el número 3316. La única descripción de este error será el texto o mensaje que le dimos a la regla de validación. Si disponemos de un control de errores en la función donde usemos este método, debemos comprobar si el número es el 3316: en ese caso, podemos cancelar la actualización con el método CancelUpdate del objeto, informar al usuario y prepararnos para insertar de nuevo tras haber modificado los valores no válidos.

Estos detalles hay que tenerlos muy en cuenta a la hora de decidirnos por una instrucción u otra, ya que tendremos que controlar el resultado.

En el ejemplo que se puede descargar desde el índice de estos apuntes,se encuentran la tabla TablaPruebas, la consulta InsercionNoValida y el formulario frmInsertar, que ilustran lo explicado en esta página.