|
Descargar
jbwzCodeGen10.zip
He realizado
varias modificaciones y le he añadido
nuevas funcionalidades que creo que merece la
pena comentar.
Texto
SQL de la consulta a String de VBA
Ahora, si el origen del recordset es una
consulta, he añadido la posibilidad de pasar el
texto SQL de ésta a una variable de texto dentro
del procedimiento generado automáticamente. Es
interesante si queremos "retocarlo", por
ejemplo, para tomar valores o añadirle criterios
a partir de alguna variable, pero, ya que cuesta
tan poco hacerlo, incluso serviría para
documentar mejor nuestro procedimiento, sabiendo
exactamente el texto SQL de la consulta que
estamos invocando.
Parámetros en consulta
La más interesante es que, con unos clics de
ratón, podemos añadirle parámetros como
criterios en la cláusula WHERE al origen del
recordset para restringir el número de registros
devueltos. Es más fácil que hacerlo en el diseño
de la consulta y, además, también generamos
automáticamente el código para dar valor a esos
parámetros.
Como explica Juan M. Afán de Ribera en su
artículo
Consulta con parámetros, el
uso de parámetros es una muy buena alternativa
para evitar los problemas de formateo de los
campos cuando construimos expresiones de
criterio para filtrar una consulta.
Como los parámetros admiten expresiones sin
formatear correctamente, son ideales para
"filtrar" a partir de los valores que
introduzcamos en controles de texto de un
formulario. Por eso, cuando usamos parámetros en
nuestro generador, le he añadido la posibilidad
de que todas las variables que se le pasan sean
del tipo Variant, para facilitar el uso de
valores introducidos por el usuario.
Para facilitar aún más que el generador
construya automáticamente el código para filtrar
un origen de registros, al añadir cada parámetro
he puesto la posibilidad de "considerar los
valores nulos" ( :- | no sabía qué nombre
darle), de manera que, eligiendo esta opción, a
cada (Parametro1 =
Mivariable) se añade un
OR (MiVariable
is null). De esta manera, conseguimos
que, si tenemos varios cuadros de texto por los
que "filtrar", sólo se considerarán aquellos que
no tengan valor nulo.
He puesto varias veces "filtrar" entre comillas,
porque no se trata de filtrar el recordset, sino
de filtrar los datos que nos devuelve la
consulta origen de éste. Para filtrar el
recordset, deberíamos usar
Filter y para
eso no nos valdría usar parámetros... Estoy ya
empezando con una futura versión que sí
utilizará Filter
y se valdrá de
BuildCriteria()
Recordset como origen de un formulario o informe
Hay veces que
resulta interesante asignar directamente el
recordset de un formulario o informe en lugar de
usar directamente un recordsource, por ejemplo
para restringir los datos o para disponer de
algunos eventos de ADO que suplan a los del
formulario.
Esta última
parte no me acaba de gustar cómo ha quedado y
espero críticas y comentarios para modificarla
en la nueva versión
|
jbwzCodeGen
