Access - Formulario con campos en cascada

Buenas noches.
Perdón si ya hay una respuesta, llevo dos días buscando y no la encuentro (he visto combos en cascada).

Estoy haciendo una base de datos con una tabla principal de ARTÍCULOS que incluye campos relacionados con otras tablas que son los TEMAS, SUBTEMAS y SUB-SUBTEMAS a los que corresponde cada artículo y relacionadas entre ellas.

ESTRUCTURA:
Tabla Principal: ATICULOS / Campos: idArticulo, Artículo, TemaNivel1, TemaNivel2, TemaNivel3
Tablas de temas:
- TemasNivel1 / Campos: idTemaNivel1, TemaNivel1
- TemasNivel2 / Campos: idTemaNivel2, TemaNivel2, idTemaNivel1
- TemasNivel3 / Campos: idTemaNivel3, TemaNivel3, idTemaNivel2

Hay más datos en la tabla ARTICULOS, sólo pongo los necesarios para la pregunta.

Cuando creo un formulario de la tabla ARTICULOS si pincho en los combobox correspondientes de TemasNivel1, TemasNivel2 y TemasNivel3 aparecen todos los registros correspondientes a cada tabla.

Lo que necesito es que en TemasNivel2 y TemasNivel3 aparezcan sólo los registros que se correspondan con el Nivel anterior. Es decir que si selecciono un TemaNivel1, en TemasNivel2 sólo aparezcan los registros relacionados con el TemaNivel1 correspondiente. Y lo mismo con TemasNivel2 y TemasNivel3.

Y además (muy importante), que el dato quede almacenado, de forma que al cambiar de registro del formulario en cada registro aparezca lo seleccionado en él.

He probado con varias soluciones que he visto sobre combos en cascada, pero al cambiar de registro se memoriza lo seleccionado en el Nivel1 del último registro modificado y no memoriza lo seleccionado en cada registro.

Si pudierais orientarme os lo agradecería.

Esta es una de las opciones que he probado con los niveles 1 y 2

Private Sub TemaNivel1_AfterUpdate()
End Sub

Otras opciones que he probado después de RowSource:

Perdón por el texto tan largo.

Sobre como funcionan las combinaciones de combos o cuadros de lista en cascada hay mucha y muy buena información y poco que añadir.

Lo que puedo aportar es:
Crear en el formulario una función (o sub-función) común a todos ellos.
En esa función comenzando por el primero y en el orden que se utilicen, regenerar el contenido de todos los combos en cada cambio que se efectúe (en cualquiera de ellos).

Aquellos que no se modificaron no se verán alterados y el resto tomaran los valores que les correspondan.

Es cierto que se pueden manipular 'a partir del modificado', pero implica mas código para poder manejar cualquier posibilidad.

En la rutina común -como se basa obtener un origen de datos basado en el anterior del que depende- si no hay un valor se le pone como origen de datos una cadena de texto vacía y se mostrara en blanco (no con un valor anterior que puede ser inadecuado).

Lo mejor: se llama a la subrutina desde cualquier sitio (combos incluidos) y presentara los datos adecuados y las modificaciones (se supone que mejoras) se hacen en un único punto.

Lo de que 'se vean los cambios'.
En ocasiones no tiene margen para repintar y mostrar los datos actuales, pero se puede forzar la presentación con un 'Me.REPAINT' como colofón del código.

Gracias por tu atención.

Cierto que hay mucha información, pero lo que he probado no me ha funcionado.

¿Podrías decirme como sería esa subrutina? o decirme donde hay un ejemplo.

Muchas gracias.

Lo que he planteado es una opción para cuando todo funcione (una simplificación lógica), mientras no funcione ¿ que se puede simplificar?.

Como tú mismo dices, hay mucha información (y te pierdes en ella). En mi caso, después de varios días buscando no he encontrado la solución.

Harto de buscar y de hacer pruebas, sigo con el mismo problema, los campos actúan como combos en cascada, pero al cambiar de registro, no se por qué razón, se pierde la información.

Por si le sirve a alguien, lo he resuelto de la siguiente manera.
No se si es muy ortodoxo, pero es una solución.

Lo he solucionado con otros combos "cboTemaN#" que actuan como combos en cascada y que contienen, temporalmente, los datos de los campos correspondientes de cada registro del formulario "cmpTemaN#".
Cuando cada cbo--- cambia, se asigna su valor al cmp--- corespontiente y se hace "Requery" y "Value = Nul" en los cbo--- de los siguientes niveles.

Private Sub cboTemaN1_AfterUpdate()
End Sub

Al cambiar de registro, los cbo--- cogen los datos cmp--- correspondientes del registro y hago un "Requery" en los niveles inferiores.

Private Sub Form_Current()
End Sub

Un saludo.

Lo que presenta un formulario son los datos que proviene de una tabla o una consulta (los datos en las tablas, los formularios interactúan con ellos).

En el formulario se puede presentar el dato 'tal cual se guardo' (un cuadro de texto) o se puede utilizar un ComboBox para presentarlo.
El combo solo muestra una columna (la que el usuario decida) pero suele tener mas de una.
Una de ellas (generalmente oculta) es el dato 'real' que proviene de su origen (tabla o consulta): la columna dependiente

Si el origen del combo esta filtrado (esa es 'la dependencia') solo presentara una parte de los datos posibles y puede darse el caso de que el elemento a presentar 'no exista en ese subconjunto filtrado' por lo que lo que tiene que hacerse es 'reconstruir el filtro' para que muestre el subconjunto adecuado.

Eso sucede para todos los combos, con excepción del primero que normalmente tiene todos los registros (es el que gobierna y no suele estar filtrado)
Al resto 'al cambiar de registro' se le ha de regenerar el origen de datos en base al valor del combo u objeto del que depende.

Una utopía , tenemos un conjunto de combos que seleccionan: un tamaño, color, objeto y familia

Se desea seguir este orden:
.- Seleccionar familia
.- Seleccionar el objeto (primera dependencia)
.- Seleccionar el color (segunda dependencia, los posibles colores de ese objeto)
.- Seleccionar el tamaño (los posibles/disponibles tamaños de de ese objeto en ese color)

En principio solo el combo de familia tendrá origen de datos
El resto tendrá como origen de datos una cadena vacía (no presentara nada ni tendrá nada que presentar)

Seleccionada una familia se le asigna al combo objetos su origen de datos (todos los objetos que cumplan la condición de pertenecer a esa familia)
Y se repite el ciclo para el resto de los combos, esto es, disponiendo del dato relacional se genera el contenido del combo.

Al cambiar de registro si el registro 'esta completo' (no es nuevo) solo hay que regenerar para cada combo el origen adecuado a su dependencia, el valor a mostrar ... el que este guardado en la tabla (se mostrara correctamente sin mas inconvenientes).

Esta manipulación que es imprescindible y repetitiva (se hace con cada modificación y cambio de registro) se puede hacer en un único punto, el mismo para todos lo que facilita el mantenimiento y generalmente es mas rápido (= llamar a la función o sub-función)

Es fácil de aplicar:
Existe un dato para familia ----> se crea el origen para el combo objetos (y se mostrara por defecto el que esta guardado)
Existe el dato familia ....... lo mismo que antes y asi para todos los combos dependientes.

¿Qué no se ha seleccionado familia ....?
El origen de datos para su combo dependiente = una cadena de texto vacía que no mostrara nada en ese combo.

Cuando se seleccione una familia (objeto, color) se llama a la sub-función que regenerara de forma correcta los diferentes orígenes de datos, en aquellos que nada ha cambiado: nada cambiara y los modificados presentaran los datos adecuados.

Pulula por la red un ejemplo que llamaron 'combos todos' que ha sido útil para muchos al permitirles entender 'como funcionan' (que es mas eficaz que buscar algo para adaptar).