| Artículos | 01 ENE 1999

Access y el problema del año 2000

Tags: Histórico
Mª Carmen Vidal.

El problema del año 2000 es una preocupación recurrente desde hace tiempo, que afecta muy particularmente a los gestores de bases de datos . Las aplicaciones Access también pueden sufrir las consecuencias del bug del milenio .

Cuando el calendario indica que faltan menos de 400 días para la llegada del año 2000, es preciso afinar las estrategias que nos salven de lo que puede ser, dependiendo de las circunstancias, un desastre o múltiples y diversas molestias en nuestro sistema informático . De entrada, definir el problema, luego testar nuestro sistema para detectar los puntos vulnerables y, finalmente, poner los parches donde sean necesarios .

¿ Qué es el problema del año 2000 ?

Cualquier persona que haya trabajado con sistemas informáticos puede testificar que, cuando es necesario introducir una información que incluya datos sobre un año, éste se suele referenciar por sus dos últimos dígitos; así el año 1998 se representa como año 98, el 1999, como año 99, etc . Las razones para ello son de lo más variado, desde la fuerza de la costumbre, que también nos hace referenciarlo así cuando escribimos o citamos verbalmente esa información, hasta razones de tipo histórico, que llevaban a ahorrar la memoria informática que se utilizaba para archivar datos, en los tiempos en que ésta tenía un precio elevado .

Pero el dato del año suele tener, en las aplicaciones informáticas, una utilidad que va más allá de la información en sí misma . Aplicaciones de bases de datos y hojas de cálculo utilizan las fechas para ordenar los registros, seleccionarlos o hacer operaciones matemáticas . En este contexto, representar el año 2000 por sus dos últimos dígitos, puede dar lugar a más de un error cuyas consecuencias irán, desde impedir que la aplicación funcione, si se utiliza en cálculos, hasta ignorar registros u ordenarlos equivocadamente . El problema se conoce ya como el bug del milenio .

Y no hay que esperar a que pase el 31 de diciembre de 1999 para que la situación se manifieste . Piénsese en todos los análisis que se basan en la proyección de datos para años posteriores al 2000; el horizonte está tan próximo que no será difícil que nos topemos con él en cualquier estudio presupuestario, desde la programación de inversiones a medio plazo en nuestra organización, hasta el no menos importante cálculo de las mensualidades con las que tendremos que amortizar nuestro préstamo personal .

La interpretación de Access sobre los 4 dígitos del año

Aunque algunos piensen que es inmune a este problema, Access es una de las aplicaciones que se puede ver afectada por el bug del milenio . Es verdad que todas las versiones de Access convierten los datos de los años expresados por dos dígitos, en años expresados con cuatro ?suponiendo un determinado valor para los dos primeros?, pero esta suposición sobre la centuria difiere dependiendo de la versión de Access que estemos considerando .

Para Access 2 . 0, todos los datos de años que representemos con dos dígitos se supone que pertenecen a la centuria que comienza por 19; así, el año 99 será en realidad el 1999 y el año 00, será el 1900 . En consecuencia, una base de datos que recoja operaciones comerciales ordenará, como más antiguas, las que hayan tenido lugar en el año 1999 ( introducido como 99 ) que las que se produzcan en el año 2000 ( introducido como 00 ) .

Access 95 hizo la suposición de que los años representados por dos dígitos pertenecían a la centuria actual, la definida por el reloj del sistema; así, si el 31 de diciembre de 1999 introducimos el dato de un año como 99, se supone que pertenece al año 1999 y si el 1 de enero del año 2000 introducimos un año como 00, pertenecerá al año 2000 . Esta suposición presenta dos problemas: por una parte, no todos los sistemas coinciden en el reloj y por otra ¿ qué pasa si en 1999 tratamos de introducir datos que se refieran a fechas posteriores al año 2000 ? ( imagine, por ejemplo, que está calculando las amortizaciones de un crédito que quiere solicitar ) .

Para evitar estos problemas, se modificó la DLL que contiene las reglas para interpretar los datos de fechas . La suposición que se hace ahora es que los años representados por dos dígitos entre 30 y 99 pertenecen a la centuria 19 y los años entre el 00 y el 29, pertenecen a la que se inicia por 20 . Esta interpretación se acepta también en Access 97 . Las bases de datos elaboradas a partir de las últimas revisiones de Access 95 contienen esta versión de la DLL modificada ?denominada OLEAUT32 . DLL?, versión que aparece también en sistemas que han instalado versiones más modernas de otros productos Microsoft, como Internet Explorer 3 . x y posteriores .

A nadie se le escapa el problema que suponen estas distintas interpretaciones . No es difícil de imaginar una aplicación distribuida, con una base de datos alojada en un servidor y con la que interaccionan distintos usuarios que manejen diferentes versiones de Access; una misma fecha referenciada por los dos últimos dígitos de un año puede ser interpretada de distinta manera dependiendo del usuario . Y esto aunque todos utilicen Access 95, si es que en el sistema de algún usuario se ha instalado software que incorpore la versión actualizada de la DLL, que contiene reglas diferentes de interpretación de fechas .

Lo que hay que asegurar

Parece, pues, que la única solución al problema del año 2000 está en que todos los datos que se refieren a años se introduzcan y representen con los cuatro dígitos . Y esto no sólo en las bases de datos que se manejen con rangos superiores a un siglo . Como acabamos de ver, no podemos dejar que el sistema interprete el siglo al que pertenece el año que especificamos por sus dos últimos dígitos, y tampoco resultaría seguro dejar que sea el usuario el único responsable de la inserción de las cuatro cifras, la inercia le llevaría a la introducción de múltiples datos erróneos y de forma aleatoria, lo que impediría su corrección de forma global .

En consecuencia, deberemos disponer nuestras bases de datos, y cualquier otra aplicación elaborada a partir de Access, para que no acepten otro modo de manipular datos anuales que no sea especificando los cuatro dígitos .

Otro posible problema es que las bases de datos de Access introducen datos, bien directamente, tecleándolos en una casilla de una tabla o en un control de un formulario, bien importándolos de otra aplicación, que no tiene por qué ser una base de datos ( puede ser una hoja de cálculo o un archivo de texto ) . Además, Access utiliza datos lógicos, es decir, datos sobre los cuales se realizan consultas, se correlacionan registros de dos o más tablas o se definen expresiones ( de cálculo o lógicas ) ; en unos y otros pueden intervenir referencias a años . Finalmente, los datos almacenados o procesados en aplicaciones de Access pueden ser exportados a otras aplicaciones, o utilizados para elaborar informes por el propio Access .

Pues bien, se debe garantizar que tanto los datos que se insertan ( físicamente o importándolos ) , como los lógicos y los que salen de aplicaciones Access ( en informes o exportándolos ) expresen los años con los cuatro dígitos .

¿ Dónde puede estar el problema ?

Para asegurarse de que una base de datos de Access no va a presentar el problema del año 2000, habrá que realizar una serie de análisis encaminados a determinar que todos los datos de años que manipula se expresan con la centuria correcta .

A ) En la introducción de datos

Una base de datos puede introducir datos directamente en una tabla o en un formulario; lo primero será determinar cuáles son los campos de todos los objetos ?tablas y formularios? que guardan información relativa a años

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información