Access - Pocos parámetros, se esperaba 4

Hola, resulta que me estoy volviendo loco con un tema en el cual llevo dos días. Si quieren ver el problema directamente sáltense el siguiente párrafo.

Tengo una base de datos con muchas tablas, particularmente una de ellas, "EVENTO_LOGISTICOS", integra dos tablas principales (fuertes) que ya se imaginarán son "EVENTOS" y "LOGISTICOS", dentro de EVENTO_LOGISTICOS exite un campo ID_EVENTO que es con el cual relaciono el formulario de eventos con un subformulario de eventos_logisticos. Los otros campos (dentro de la tabla EVENTOS_LOGISTICOS) que intervienen en el problema son: hora_entrada, hora_salida, id_logistico y fecha .

Lo que quiero hacer es validar que no se pueda ingresar un rango de horario de trabajo de un logístico que ya se encuentre en la tabla EVENTO_LOGISTICOS, es decir, si un logístico con el ID_LOGISTICO 100 tiene registrado un rango de horario trabajado de 9am - 5pm, el subformulario no debería permitir ingresar un rango de horario de 10am - 2pm pues se supone que ya trabajó en el rango horario anterior (todo esto sobre el mismo día). Algo así :

Si el rango de horario que está en la base de datos es A, en el subformulario se debe validar que no se puedan ingresar rangos horarios como B, C o D.

Para eso he intentado trabajar con una consulta que valide justamente que esos rangos no se presenten en la base de datos; lo intenté con DLOOKUP y fue frustrante. traté de hacer la sentencia SQL y presentaba errores que la verdad no sé de dónde salieron (creo que era comparando las horas, algo con los formatos) y finalmente estoy tratando de llevar una consulta que creé directamente con el diseñador de consultas para almacenar los resultados en un Recordset y así poder trabajar con ellos pero me muestra el error "Pocos parámetros se esperaba 4". La consulta funciona perfectamente cuando la ejecuto con access, aclarando que en access me toca cambiar los criterios como [Formularios]![fEventos]![fEvento_logisticos]![ID_LOGISTICO] por datos reales. La consulta es:

La sentencia que uso en VB es:

Cabe anotar que la consulta en la base de datos efectivamente se llama "Consulta Horas Coincidentes Logísticos", el evento sobre el cual estoy programando es "Form_BeforeUpdate" y el código ejecutado no llega ni al primer If pues al recordset nunca le llega información y saca el error.

No sé si estoy yendo por el camino equivocado, no programo mucho en access y menos SQL (la sentencia sql de la consulta es la que crea access, traté de ordenarla lo que más pude).

Siento mucho si me extendí en la explicación pero era para contextualizarlos lo que más pudiera

Agradezco su colaboración.

Dependiendo del entorno (local o intranet), esto es en la propia maquina o aplicación dividida y con DAO, normalmente suele dar un soberano cero en el RecordCount (no lo garantizo si no es local y en la propia base sin dividir).

Si se quiere tener una información real y veraz de la cantidad de registros de un recordset, se le tiene que 'agitar' bien y aquí no se hace.

Nadie sabe con certeza como están los datos dentro de Access y el recordset al cargarse puede finalizar la carga en cualquier punto (para el orden están los índices, el resto a Access le es indiferente, con saber donde están no necesita ponerlos en fila físicamente.

En estas circunstancias (esto es: si el método de RecordCount <> 0 no es valido), se tendría que verificar que no se esta al mismo tiempo al inicio y al final (un 'antes' y un 'después' al mismo tiempo, no dejan espacio para algo en el medio, así que hay que verificar el EOF y el BOF).

Una vez que se delata que el recordset tiene contenido (sea un único registro o la guía de teléfonos de Tokio) lo habitual es 'pasar lista' esto es: desde el inicio al final (irse al principio y después al final del recordset) y luego se le pregunta ¿Cuántos hay?, porque si se le envía al principio y final cuando no tiene registros el recordset … a Access 'se le corta la digestión' (supongo que será por eso lo de devolver un error).


Analiza el rendimiento de lo que pretendes, creando una consulta mas elaborada en base a hacer consultas restrictivas que se lancen desde la consulta principal (que aunaría a las parciales que la integran).

El planteamiento que yo haría, consistiría en trabajar con el mínimo de elementos posibles, con el fin de que la consulta devuelva resultados mas fieles

Que abarca un rango de fechas … descarta a los que finalizan antes y comiencen después (por ejemplo) y no hay que perder de vista que una consulta puede llamar (utilizar) otra consulta y esta a otra … con lo que con un poco de 'picardía' se puede generar una consulta que según avanza va perfilando (en calidad y cantidad) el resultado final.