Quien no se ha topado con el problema de tener que relacionar diferentes tipos de bases de datos y que la fecha sea un dolor de cabeza?, el que no halla tenido ese problema es porque o toda su informacion esta en un solo tipo de BD (Gracias SQL!) o porque no tiene retos en su vida. Casi todo el mes pasado estuve investigando como relacionar fechas de Access (Mugrero!) con las fechas de SQL Server 2005 (Excelente!), el problema era que el campo de fecha en SQL seguia el formato tradicional de yyyy-mm-dd y en Access el campo de fecha no era ni siquiera Date, era string, para acabarla estaba en este formato dd/mm/yy.
Tomemos en consideracion que probablemente el problema desde el principio es el formato string de la fecha en Access (digo a quien se le ocurre no hacerlo "DATE" habiendo en estos dias tantas funciones y facilidades para utilizar tipos de datos), pero nos enfocaremos en el problema resultante de estas variables.
Al momento de consultar las bases de Access (desde un programa hecho en VB 6.0 SP6 con los controles de Microsoft ActiveX Data Objects 2.8) sabia que tenia que convertir la fecha a algo que pudiera definir rangos, si utilizaba la funcion CONVERT de SQL el programa marcaba error ya que estoy consultando Access, a pesar de ser compatible la "Jerga" de SQL con numerosos tipos de BD en algunas ocasiones se deben utilizar funciones propias del motor de BD al que va dirigido la consulta (un ejemplo de esto seria la funcion CTOD de Fox Pro la cual si jala muy bien) pero en el caso de Access con la funcion CDATE los resultados eran verdaderamente extraños, o traia todo lo que habia en la base de datos o de plano nada o rangos totalmente opuestos a lo que le pedia (un tipo de efecto "Outer Join" era el que mas me molestaba). Despues de batallar durante una semana probando toda funcion posible (si, dije una semana) decidi exportar los datos a SQL en una tabla temporal, sinceramente crei que no funcionaria, que marcaria errores etc,etc, pero para mi sorpresa la tabla se exporto correctamente!, entonces vino lo malo de la situacion, para cada consulta o reporte tendria que estar exportando los datos a SQL?, pues si, como urgia el reporte que tenia que sacar asi lo deje. Dias despues no podia olvidar el asunto, mas que nada porque sabia que en un futuro tendria que hacer mas reportes y la idea de no hacer una consulta directa francamente me molestaba. Investigando mas a fondo me di cuenta que este tipo de situaciones se deben a numerosos factores:
-La configuracion regional.
-La gran idea del formato dd/mm/yy en string no era lo mas optimo.
-En el caso de "ligar" los datos de Access con SQL, la colacion del servidor.
-El motor de base de datos de Access es realmente limitado (es mas eficiente el de FOX).
-La version del control Microsoft ActiveX Data Objects 2.8, mezclado con la version de Access,
y la configuracion regional suelen ser un gran problema a veces debido a que cada uno
funciona distinto.
-Como punto aparte pero no menos importante, no solo mi sistema accesa a las tablas de Access y SQL, hay programas externos en la empresa en la que trabajo por lo cual no podia cambiar ciertas configuraciones a mi antojo y debia encontrar un "Workaround".
La solucion?, facil, traer todos los datos de Access (ya que la consulta si funciona mientras no defina rangos de fechas) y despues filtrar manualmente haciendo una funcion de VB6, optimo? claro que no!, asi que decidi que este seria mi ultimo recurso.
Despues de mucho buscar increiblemente encontre articulos y comentarios en foros de como mucha gente se rendia totalmente y preferia exportar los datos a SQL, era acaso que Access nos tenia pescados a todos de los $&"!\#?. Ok, me disculpo por esa expresion, el caso era que incluso encontre en la pagina de soporte de Microsoft un "Boletin" acerca del problema en el que el mismo Microsoft decia algo asi:
"Se ha reportado el problema con las fechas al momento de exportar o consultar datos en Access, le sugerimos seguir las siguientes recomendaciones, bla, bla, bla."
En pocas palabras recomendaban transformar las fechas de todas maneras hasta que quedara, y si no?, descaradamente decian que exportaras los datos a SQL!, no lo podia creer!, ellos mismos aceptando que Access no vale un cacahuate! (Ok si vale pero tanto como confiarle aplicaciones importantes la verdad prefiero DBF-FOX, lento pero seguro, ademas este es solo uno de los tantos problemas que he tenido con Access en mi opinion muy personal).
Aun asi no queria llenar a cada rato el servidor de tablas temporales, al menos cuando hice las mil y un pruebas de conversion de fechas me di cuenta que al menos si podia filtrar por mes y año (en cuanto agregaba dia valia queso el asunto), de esta manera traer los datos no tardaba demasiado y funcionaba bien con una funcion que utilize para filtrar manualmente en VB6.
Existen rumores de entre todas las paginas que encontre en donde hacian mencion del problema (las cuales fueron muchas!) de que si se puede solucionar el problema con alguna intrincada combinacion de funciones (la cual solo presumian pero no compartian), por el momento cumpli el objetivo, pero Access debera prepararse para cuando tenga algo de tiempo libre, ningun programa escapara a la furia de este ingeniero en sistemas ;).
Aqui estan algunas de las paginas mas importantes que mencionaban algo de esto o que me ayudaron:
Would you like to know more?
http://support.microsoft.com/kb/208591/eshttp://support.microsoft.com/kb/210276http://www.guillesql.es/Articulos/SQLServerFAQ_Como_Fechas.aspxhttp://support.microsoft.com/kb/286222http://www.cse.dmu.ac.uk/~mcspence/Access%20and%20VBA%20FAQ.htmhttp://weblogs.sqlteam.com/jeffs/archive/2007/03/30/Quick-Access-JET-SQL-to-T-SQL-Cheatsheet.aspxSi no quieren tanto rollo (flojos) al menos vean esta pagina.
http://forums.devarticles.com/microsoft-access-development-49/ms-access-date-range-query-problem-3698.htmlMas adelante seguire posteando este tipo de casos que son parte de mi experiencia personal.
P.D. Consideren mi Post como una prueba fiel de que estoy en desacuerdo con el "Seguir leyendo" :) .
Huston out.
