Access - Combobox anidados no me guarda datos en tabla

Hola,
Llevo unos días dándole vueltas para ver cómo hacer lo siguiente. Tengo varios combobox anidados.

cboDiseñador y sus anidados
cboPais y sus anidados

Hice una prueba añadiendo el primer registro y todos se guardan en la tabla principal (T_PRINCIPAL), salvo los combobox dependientes.

Hice una prueba con el propio dato de la tabla principal, y está correcto, peeeero, lo que no quiero es que me guarde el autonumérico, sino el nombre del diseñador o país elegido en el combo

Mejor adjunto la base para que entiendan lo que quiero decir ;)
por cierto, la foto tampoco me la guarda, supongo que es porque el dato no se guarda en el campo de la tabla, ya que creé un control de imagen desde el formulario, pero entonces, ¿cómo hago?

El form para abrir se llama F_PRINCIPAL


Gracias de antemano

• DBMM_mayo2024.rar(3,8 MB)

No tengo claro que el registro (el unico registro que hay) se crease utilizando el formulario.

En base al diseño de las relaciones entre tablas, lo que se guarda en el campo 'Diseñador_ID' es el ID de la tabla 'T_DISEÑOS' y el nombre del diseñador esta en la tabla vinculada 'T_DISEÑADORES'

Lo que llama la atención es que en 'T_DISEÑOS' solo hay un registro, su ID es (4) y en 'T_PRINCIPAL' aparece un (5) y ese dato no existe ....

Para que el combo [Cuadro_combinado778] muestre los nombres en lugar de los ID de los diseñadores, el origen de datos deberá ser una consulta con las tablas [T_DISEÑOS] y [T_DISEÑADORES] que están relacionadas asi:

[T_DISEÑO].[NombreDiseñador] <<<===>>>> [T_DISEÑADORES].[IdDiseñador]

Se tomarán los campos [IdDiseño] de la tabla T_DISEÑOS y el campo [NombreDiseñador] de la tabla T_DISEÑADORES.

(Personalmente modificaría en la tabla T_DISEÑOS el nombre del campo [NombreDiseñador] a [IdDiseñador] para evitar confusiones)

En la tabla principal se continuara guardando el dato adecuado (Id del diseño) y en el combo se visualizará el nombre del diseñador.

Si lo anterior soluciona lo que necesitas y si lo deseas, continuamos con el resto.

Por cierto, en las tablas solo se guarda un único dato por cada campo, si deseases que también se guarde el nombre del diseñador de ese diseño, se tendra que añadir en la tabla un campo para ello (algo que no es adecuado en un diseño RELACIONAL).

Hola Anónimo, te contesto por partes:

"No tengo claro que el registro (el unico registro que hay) se crease utilizando el formulario."

El único registro que hay lo añadí desde el formulario, creéme ;) es solo un registro porque estaba haciendo una prueba, me ha pasado muchas veces que comienzo a añadir registros y sigo arrastrando errores ;)

En base al diseño de las relaciones entre tablas, lo que se guarda en el campo 'Diseñador_ID' es el ID de la tabla 'T_DISEÑOS' y el nombre del diseñador esta en la tabla vinculada 'T_DISEÑADORES'.

Sí, porque donde realmente está toda la información es en la tabla T_DISEÑOS, y T_DISEÑADORES solo es para generar los nombres y añadirlos a la tabla T_DISEÑOS con su correspondiente información (a no ser que me indiques que debería ser de otra manera). Mi nivel es así, así ;)

Lo que llama la atención es que en 'T_DISEÑOS' solo hay un registro, su ID es (4) y en 'T_PRINCIPAL' aparece un (5) y ese dato no existe ....

Lo que te comenté al principio, estaba creando un solo ejemplo, pero lógicamente hay miles de diseñadores, pero estoy creando desde cero esta base (tengo muchas otras de otros años, pero siempre tengo algo nuevo).
El 4 es el id de la tabla T_DISEÑOS y el 5 es el id del diseñador, que lo encontrarás en la tabla de T_DISEÑADORES.

Para que el combo [Cuadro_combinado778] muestre los nombres en lugar de los ID de los diseñadores, el origen de datos deberá ser una consulta con las tablas [T_DISEÑOS] y [T_DISEÑADORES] que están relacionadas asi:

[T_DISEÑO].[NombreDiseñador] <<<===>>>> [T_DISEÑADORES].[IdDiseñador]

Se tomarán los campos [IdDiseño] de la tabla T_DISEÑOS y el campo [NombreDiseñador] de la tabla T_DISEÑADORES.

(Personalmente modificaría en la tabla T_DISEÑOS el nombre del campo [NombreDiseñador] a [IdDiseñador] para evitar confusiones).

En la tabla principal se continuara guardando el dato adecuado (Id del diseño) y en el combo se visualizará el nombre del diseñador.

El combo [Cuadro_combinado778] es una prueba para ver cómo puedo elegir el nombre del diseñador y no su id, así que realmente no existe en la versión final de la base ;)
En otro test, conseguí que aparecieran los nombres en dicho combo, modificando su origen de la fila, pero no conseguía que apareciera su dato correspondiente en el combo cboVestimenta (dependiente de aquel, que sí conseguí con el combo cboDiseñador, pero no se guarda en la tabla principal).

Cambio lo de [NombreDiseñador] a [IdDiseñador].

Si lo anterior soluciona lo que necesitas y si lo deseas, continuamos con el resto.

Continuamos, continuamos ;)

Por cierto, en las tablas solo se guarda un único dato por cada campo, si deseases que también se guarde el nombre del diseñador de ese diseño, se tendra que añadir en la tabla un campo para ello (algo que no es adecuado en un diseño RELACIONAL).

En la tabla principal tengo el campo relacionado con el diseñador, no entendí muy bien esta parte.

Por cierto, mil gracias por tu ayuda... de todas formas, creo que tengo un buen lío creado, no sé si me vale la pena seguir :(

Vamos a intentar arreglarnos con lo que ya hay.

Borremos el combo ‘Test’ (Cuadro_combinado778) y modifiquemos el combo ‘cboDiseñador’

Se añade una columna más (en lugar de una, dos) el ancho de las columnas es cero para la primera y el que tiene por diseño para la segunda:
0cm;8,177cm

En ‘Origen del control’ (pestaña datos), seleccionar el campo: IdDiseño

A su ‘Origen de la fila’ (RowSource) se le añade un dato más:


Con estas modificaciones, el combo presentara el nombre del diseñador que se obtiene de la combinación (diseño + diseñador)

Comenta si funciona como lo necesitas.

Para ‘cboPais’ las modificaciones son similares, se añade un campo más en la consulta y una columna más en el combo, se le asigna el campo (del origen de datos del formulario) que le corresponda.

Las imágenes mejor ‘fuera’ de la base, lo que se suele guardar es la ruta de acceso a ellas, para poder dar una idea se necesitaría una visión general de lo que se pretende y detalles como si habrá más de una por registro (entre otras cosas).

Hola,
Lo primero es agradecer tu tiempo ;)
Durante estos días lo he seguido intentando, incluso modificando el nº de columnas antes de que me lo comentaras. Las tablas anidadas funcionan en todos los casos, pero no se guarda la información en la tabla principal.
He hecho también lo que me has comentado, pero me aparece el siguiente error:

En base a tu respuestas anteriores, di por supuesto que en la tabla 'T_Diseños' el campo de relación con la tabla 'T_Diseñadores' ya compartían el nombre, es por ello por lo que solicita ese dato.

Solo se necesita CAMBIAR' en la tabla T_DISEÑADORES el nombre del campo [NombreDiseñador] al nombre que se le debío adjudicar cuando se diseño que siempre debió haber sido [IdDiseñador].

Ese error lo he apreciado en mas tablas, que el mismo dato (el que se utiliza para relacionarlas) en una tiene un nombre y en la otra otro diferente (algo que siempre generara conflictos).
(por ejemplo: en una IdDiseño, en el otra Diseñador_ID)

El campo de relación entre tablas tiene que ser del mismo tipo (ha de mantenerse la coherencia) y una forma de 'evitar' esos errores (si es de texto que uno solo admita tres caracteres y el otro cuarenta) es: (con ambas tablas en modo diseño) copiar el campo de una a la otra
.
Así 'se garantiza' que son IDENTICOS y podrán generar una correcta relación.

Pregunta .... ¿Que sentido tine que en una el campo sea un numero y se le llame IdDelGato y e la tabla con que se relaciona (en la que también es numérico) se le denomine NombreDelGato? (que ademas existe en la 'otra tabla' como texto)

En la tabla se guardara el valor de la columna dependiente del combo:
El de la columna (la numero uno) que esta oculta (ancho de cero) y se corresponde con el ID del diseñador que se ha obtenido mediante la consulta que da origen al RowSource del combo.

Hola de nuevo,
Antes de ver tu mensaje conseguí que apareciera el nombre del diseñador con el origen de la fila, y el resto de los combo están perfectamente anidados:

SELECT DISTINCT [T_Diseños].[IdDiseño], [T_Diseñadores].[NombreDiseñador], [T_Diseños].[Vestuario], [T_Diseños].[Diseño] FROM T_Diseños INNER JOIN T_Diseñadores ON T_Diseños.Diseñador_ID = T_Diseñadores.IdDiseñador ORDER BY [T_Diseñadores].[NombreDiseñador], [T_Diseños].[Vestuario];

No obstante, el hecho de poner diferentes nombres a pesar de ser "el mismo" campo, es porque siempre he creído que era mejor así, ya que hace años, cuando ponía los mismos nombres de campo, me liaba porque no sabía de dónde lo estaba cogiendo (sobre todo porque quería entender el código), y a partir de ahí comencé a utilizar nombres diferentes pero cambiando la nomenclatura un poco. Pero veo que no es lo más correcto ;) Tendré que cambiarlo todo para que esté bien.
Además, comentas que en la tabla de diseñadores, el texto corto NombreDiseñador realmente debería ser IdDiseñador, al igual que en la tabla diseñadores. Pero es que IdDiseñador es el autonumérico de la tabla diseñadores...

Nota: vaya... acabo de añadir algunos nombres iguales en la lista de diseñadores y DISTINCT no ha hecho su trabajo :(
creo que me rindo, llevo muuuuchos días con estas dichosas listas anidadas.

Por los comentarios, creo que no esta correctamente planificada la aplicación, pero es mi punto de vista dado que no se que se pretende obtener.

Sobre los nombres...
El mismo dato no debería llamarse de diferentes formas (dos o mas según lo has planteado), en el supuesto de que se utilice en mas de una ubicación (tabla), solo hay que añadirle el nombre de la tabla (a modo de apellido) y de esa forma se evitan inconsistencias si ambos coinciden en alguna SQL o procedimiento, si no coinciden en el mismo código y se desconoce de donde viene pues .... no se están haciendo bien las cosas (sean nombres iguales o diferentes).

Que al nombre de un campo se le anteceda de 'ID' no lo convierte de facto en una propiedad, la propiedad se le asigna al campo (no a su nombre) y un dato 'autonumérico' no es mas que un dato numérico (de tipo entero largo) al que Access le da un tratamiento especial.

lo que hace esa propiedad es incrementarlo y no repetirlo, Access es tan critico con los autonuméricos, que si se inicia un nuevo registro y (sin llegar a finalizarlo) se borra o se crea y tras ello se borra: el numero se pierde.

El mismo dato autonumérico -que puede ser o no la llave en una tabla- si se copia a otra tabla, en la tabla que lo recibe aparece sin esas propiedades activadas (como lo que es: un simple numero) y ello permite construir las relaciones 1 a N (las clásicas entre una tabla principal y otra relacionada).

Respecto a DISTINCT hay mas opciones en las consultas (depende de lo que se necesite) una es DISTINCT, otra DISTINCTROW y aun queda la alternativa de las consultas de agrupación .

Solo a titulo de curiosidad:
Si asimilásemos a la tabla T_PRINCIPAL como el esqueleto de la aplicación:
Qué seria para ella la tabla T_DISEÑOS, en principio parece que el brazo y al final de el T_DISEÑADORES la mano y dedos.
Tal como esta parece que se desea obtener un dedo y para llegar a el se precisa recorrer el brazo ...

En definitiva ¿ese campo en T_PRINCIPAL se utiliza para guardar el diseño o al diseñador?.

Todo depende de que que se desee obtener, y si un diseño puede tener mas de un diseñador, lo normal es agruparlos como supuesta sociedad para ese diseño (y la sociedad tendría su particular ID del que dependerán los que conforman esa sociedad).

Hola, llevo todo el día con esto, leyendo sus comentarios y viendo numerosos vídeos, está conseguido. Finalmente he modificado la estructura de mis tablas para obtener los resultados y también he puesto el mismo nombre a los campos que corresponden, y se guardan correctamente en la tabla.

¡Muchas gracias!