EL BLOG DE ACCESS

Despues de unas merecidas vacaciones he vuelto al trabajo con nuevas ideas para la pagina, despues de 6 meses me ha sorprendido la cantidad de visitas y de gente que me ha preguntado cosas a traves del mail, todo esto me ha dado fuerzas para seguir aumentando las secciones (muy pronto), y estas son algunas cosas que se me han ocurrido:

-Seccion SQL del foro: para que me mandeis vuestras consultas sql, que yo y el resto de gente intentaran resolver

-Seccion de programacion PDA Avanzado: Tras el exito del primer maual para programar pdas he pensado avanzar en la materia con nuevos lenguajes de programacion para PDAS y nuevas e interesante funcionalidades

Despues de una semana trasteando con procedimientos almacenados puedo decir que la diferencia es impresionante, he mejorado la velocidad de los calculos en mas del 50%, mi codigo esta mucho mas estructurado y claro. Pero no todo son ventajas, a la hora de compilar, sql server no nos va a dar muchos datos de los errores de compilacion, asi que tendremos que buscarnos la vida para arreglarlo.

Los procedimientos almacenados es como todo…cuando has echo 20 el resto te salen como churros, es cuestion de practica, y notareis la diferencia de velocidad y eficiencia….

Hoy vamos a ver el codigo necesario para poder ejecutar un store procedure de sql server desde visual basic acces:
Dim cmd As New ADODB.Command
Dim params As ADODB.Parameters
Dim Param As ADODB.Parameter

‘ Iniciar las propiedades del procedimiento
With cmd
    Set .ActiveConnection = CurrentProject.Connection
    .CommandText = “CalPeces”                                       -nombre del procedimiento
    .CommandType = adCmdStoredProc
    .CommandTimeout = 0
    Set params = .Parameters
End With

‘ Definimos uno por uno los parametros de entrada del procedmiento.
params.Append cmd.CreateParameter(”@Donde”, adVarChar, adParamInput, 3)
params.Append cmd.CreateParameter(”@Norcod”, adVarChar, adParamInput, 15)
params.Append cmd.CreateParameter(”@fechaini”, adVarChar, adParamInput, 10)
params.Append cmd.CreateParameter(”@Fechafinal”, adVarChar, adParamInput, 10)
params.Append cmd.CreateParameter(”@TipoPeriodo”, adVarChar, adParamInput, 1)

‘ Especificamos los valores de estos parametros
params(”@Donde”) = capa.Value
params(”@Norcod”) = norma.Value
params(”@fechaini”) = fechaini
params(”@fechafinal”) = fechafinal
params(”@TipoPeriodo”) = “M”
‘ Execute the command
cmd.Execute , , adExecuteNoRecords                    -ejecutamos el procedimiento
‘Set sp_ICG_Recalcular_1 = cmd.Execute

manaña mas……

Ha llegado el momento de dar el siguiente paso: pasar mis aplicaciones vba con el codigo sql embebido a store procedures….Es un cambio logico y que hara que mis aplicaciones funcionen mas rapidas y esten mejor estructuradas.

Un Store procedure no es mas que codigo sql al que podemos pasar una serie de parametro y añadir programación, como pueden ser bucles o condiciones. Estos procedimientos se almacenan en la propia base de datos y no en el codigo de la aplicacion. En los store procedures declararemos las variables de entrada con un “@”. Y desde mi codigo VBA llamaremos a estos procedimientos pasandole los argumentos necesarios.

Con esta mejora reduciremos la carga de codigo en nuestros adps y se la pasaremos a sql server, experimentando una mejoria en velocidad, y ademas tendremos el codigo estructurado en pequeños modulos dentro de la base de datos

Sin duda la respuesta para mi es la programacion “a pelo”. Para cualquier programador, el utilizar macros puede llegar a ser engorro, ya que crea codigo “basura” innecesario (”complicado de entender a posteriori”).

Mi experiencia me dice que es mucho mas eficiente crear modulos y funciones de toda la vida con programación secuencial. Posteriormente generaremos un evento y accederemos a  las funciones de esos modulos directamente.

 Los macros de access pueden resultar tremendamente utilies para gente con pocos o nulos conocimientos de programacion, pero para programadores con algo de experiencia el trabajar con modulos resulta mucho mas eficiente y rapido.

Uno de los primeros problemas que me plantee cuando empece a desarrollar aplicaciones VBA era que no parecian aplicaciones, sino bases de datos access. A vista del cliente queda muy “feo” abrirle una base de datos access y que tenga que buscar los formularios adecuados.

Access nos permite configurar una serie de opciones para que nuestras aplicaciones parezcan mas “amigables”. Para ello nos situamos sobre el menú de la base de datos (el recuadro con las opciones: tablas, consultas, formularios, informes, macros etc…) y pulsamos el boton derecho y la opcion “Inicio 1.- titulo de la aplicación: lo que pongamos aqui aparecera en la parte superior izquierda de la ventana de la base de datos 2.- Icono de la aplicacion: un pequeño icono que aparecera a la izquierda del titulo, recordar que la imagen tiene que guardarse con formato ico3.- Mostrar formulario/pagina: Aqui le indicamos el formulario que debe aparecer automaticamente al arrancar la aplicacion, podemos crear un formulario especifico con enlaces a todos los formularios de la aplicacion

4.- Presentar la ventana de la base de datos: Evita que el usuario pueda acceder a las tablas, consulta etc de la base de datos, ideal para usuarios “peligrosos”

5.-El resto de casillas de verificación se refieren a opciones de visualizacion de barras de herramientas, cuantas mas opciones desactivadas mas aspecto de “aplicacion” tendra nuestro ADP

A continuacion os muestro algunas cosas interesantes de sql server que no me enseñaron en mi carrera ( que raro…..) y que me han venido bastante bien a la hora de hacer las consultas:

1.FECHAS: Cuando se trataba de comprar fechas, buscar por intervalos de fechas o buscar los parametros de un mes o año en concreto, me las tenia que apañar  con cosas como esta:

      buscar cosas de diciembre de 2005: select * from cosas where fecha like ‘%12/2005′.   Esto en terminos de programacion es un chapuza, pero bueno, asi me las apañe unos meses. hasta que descubri YEAR,MONTH y DAY, que funcionan de la siguiente manera:

select * from cosas where YEAR(fecha) = 2005 and MONTH(fecha) = 12 . Parece una tonteria pero acorta el trabajo…

Hoy voy a explicar brevemente como desarrollar aplicaciones sencillas para instalar en cualquier PDA y que pueden ahorrarnos una gran cantidad de trabajo….

Solo necesitaremos tres cosas:

-Microsoft Visual Basic Embebed Tools 3.0 o superior (si es que existe)

-el parche para aplicaciones visual basic para pdas (en breve pondre un link de descarga)

-Una base de datos access

En primer lugar cargamos el parche en la pda, pero no con el active sincy, si no con el explorador normal de windows

lo copiamos y lo pegamos en la PDA, y desde la PDA lo ejecutamos. Ahora ya podemos tener aplicaciones EVT en nuestra PDA.

Ahora arrancamos el Embebed visual tools y comenzamos a trabajar. Los formularios tienen opciones reducidas, pero es muy sencillo programar.

Yo desarrolle una aplicacion para insertar una serie de datos analiticos. El personal de la empresa va lugar con la pda, selecciona el lugar en un desplegable, y rellena los datos que se observan en ese sitio. Una vez terminado guarda los datos y vuelve a la pantalla principal.

Cuando el personal vuelve a la empresa descarga la base de datos de la aplicacion (access) a su ordenador, y puede ver que toda la informacion queda recogida en una tabla.

 La semana que viene colgare en la pagina todos los pasos para generar una aplicacion con EVT, desde la conexion a la base de datos, hasta la creacion de formularios. Si no podeis esperaros no dudeis es poner vuestras dudas en el foro de la pagina o contestando a este blog

gracias

A lo largo de mi experiencia como programador me han ido surgiendo problemas a la hora de convertir consultas de access a sql server y viceversa:

1.- A la hora de hacer consultas de comparación de strings, access utiliza el simbolo * para referirse a cualquier caracter, mientras que sql server utiliza el simbolo %. Debido a esto, las consulta que habia desarrollado con access no me funcionaban en los adps, y la verdad es que me costó averiguar el problema, ya que la consulta no da fallo, simplemente no devuelve un resultado

2.- Problemas con count distinct: Access no admite consultas del tipo Count (distinct COD) , pero sql server si. Si tenemos un ADP con esta consulta funcionara perfectamente, otra ventaja de trabajar con adps