Access - encontrar registros en subformulario

Hola a todos.

Estoy creando un formulario para registrar los pedidos y los productos asociados a cada pedido.
Lo he estructurado de la siguente forma:

He creado un formulario que contiene los datos generales del pedido (cliente, fecha del pedido, ubicación de los productos, etc.).

Dentro de este formulario he creado un subformulario que contiene productos y cantidades de cada producto.

Formulario y subformulario están vinculados por 2 campos:
- Id de pedido que es el campo clave de la tabla (y formulario) pedidos
- Nº de pedido que es el campo relacionado en la tabla (y subformulario) de productos.

Adjunto un pantallazo de esta parte del formulario para que se vea con más claridad.

En el formulario principal, si navego por los registros voy avanzando por el pedido nº1, 2, 3, 4...
Al mismo tiempo, el subformulario me va mostrando los productos asociados al pedido nº 1, los productos asociados al pedido nº 2, etc...Por defecto, los pedidos están ordenados de fecha de expedición más temprana a fecha de expedición más tardía.

La duda que tengo es cómo crear una herramienta que me permita buscar un producto concreto bien con un combobox o con un campo de búsqueda y me lleve a él (o al registro que lo contiene en el subformulario de productos asociado a un pedido concreto) respetando el orden de los pedidos y que, a medida que vaya pulsando el intro, me salte al siguiente pedido más urgente que contenga ese producto y vaya avanzando por todos los pedidos hasta llegar al pedido menos urgente que contenga el producto. Como un buscar siguiente de excel o de word.

Con la herramienta de búsqueda por defecto que aparece en los botones de formulario, sólo me busca en los registros asociados al pedido que estoy visualizando en el momento. Pero cuando vuelvo a pulsar intro, no me lleva a otros pedidos que contienen ese producto.

Lo más parecido que he conseguido es hacer una búsqueda con recordsetclone abriendo un formulario que me muestra el producto que busco y los nºs de pedido asociados en una ventana independiente, pero no me parece operativo porque hay que memorizar el nº de pedido y hacer una búsqueda adicional por nº de pedido en el formulario principal.

Pongo aquí el código de lo que indico más arriba en la búsqueda del recordset. Aunque como decía, no me sirve:


Os agradezco cualquier aporte.

Un saludo

No me parece un enfoque correcto.

EL RecordsetClone del subformulario solo tiene los registros que dependen del formulario principal y con la excepción de que tengan algún registro duplicado (mas fácil es cambiar la cantidad) solo habrá una coincidencia (si la hay, claro).

Hay que plantear la solución desde otro ángulo: ¿Qué y cuantos pedidos tienen lo que se busca?.

Para saber si la búsqueda puede devolver algo (y si es no abortarla) se puede utilizar DCount sobre la tabla 'detalles del producto' de forma genérica (si no se utilizo en ningún pedido … devolvería un cero).

Si la respuesta no es un cero es que hay algún pedido que contiene ese producto y habrá que hacer una selección para que solo se muestren pedidos con ese contenido.

Una consulta de selección con las tablas implicadas y como condición lo que se busca, devolvería solo los pedidos que nos interesan y se puede utilizar como origen de datos del formulario principal.

Muchas gracias por el aporte.

Sin embargo, con la propuesta, creo que obtendría un resultado similar al recordset que he puesto en mi primer mensaje.

Es decir, creo que aparecería un listado de los pedidos que contienen ese producto (por favor, corregidme si me equivoco). .

Pero, lo que intento es que la búsqueda haga que el cursor (o foco, no sé si es más correcto) se desplace entre los distintos registros del formulario principal (simple) y localice en el subformulario (continuo), campo productos, aquellos registros que coincidan la palabra escrita.

Por poner un ejemplo más concreto, si estoy visualizando el registro del formulario principal, pedido nº1 que corresponde al registro nº1, y en el campo de búsqueda escribo el nombre de un producto, por ejemplo, tornillo 5 mm, y el primer pedido que va a contener este producto está en el registro nº4 del formulario (pedido nº 4). Al pulsar intro, el foco debería desplazarse al 4º registro del formulario principal (pedido nº 4) e ir al campo de producto, exactamente al registro que contiene el nombre del producto. Cuando pulse de nuevo el intro, debería ir al siguiente pedido con ese producto, por ejemplo registro nº 7 del formulario principal, pedido nº 7, exactamente en el registro dentro del campo producto el subformulario que contenga ese nombre.

No sé si es posible esta búsqueda directa, saltando de registro en registro sin búsquedas intermedias. Buscando en la red no he encontrado nada parecido. Necesito hacerlo de este modo porque los usuarios del formulario no tienen experiencia manejando sofware de ofimática.

Con un enfoque correctamente definido y un dominio acorde a la necesidad, se puede hacer con Access (y con cualquier programa) lo que sus limites permitan.

Si se llegase a modificar el origen de datos del formulario, con un subconjunto de registros que cumplan la condición de que 'en otra tabla asociada' -los detalles de cada registro filtrado- contenga un tipo de dato concreto ….

Tras el registro numero uno (y que tiene ese dato buscado al se toma como referente), el supuesto n. 4 seria en la practica el n. 2 (al dos y tres ese 'filtrado' los elimina del subconjunto), y el nuevo tres, cuatro …. es decir 'todos ' los registros tendría como sub-elemento el dato referenciado.

Mas claro:
.- Un conjunto de personas diversas.
.- llama la atención un tipo de calzado y 'se filtra por ese elemento'
.- el resto de personas que no tiene ese elemento 'se eliminan del conjunto'
.- el resultado será siempre que los que se quedan … tienen ese tipo de elemento (el calzado) y obtendrán un nuevo numero de orden en la nueva lista.

Como se planifique es cuestión de gustos, mi planteamiento (el del mínimo esfuerzo), me aconseja que verifique si vale la pena molestarse en filtrar (porque si filtro y no hay datos el usuario pensara que acaba de perder el esfuerzo de todo el mes) ….