Access 2000
Hola, en estos momentos estoy intentando crear una base de datos mientras aprendo el manejo de access.
Mi problema es que tengo dos tablas: ARTÍCULOS COMPRADOS Y ARTICULOC VENDIDOS y que tienen 5 columnas que son iguales, todas situadas en el mismo orden y con el misnmo tipo de datos como indica Access. Pero tengo que hacer que elegido en una columna (dicho valor debe obtenerse de una consulta a la otra tabla) entonces el resto de las columnas se actualicen automáticamente con el valor que le corresponde en la otra tabla según ese valor elegido y después borrar ese registro en la tabla origen, es decir, hacer una transferencia de tabla comprados a vendidos.
GRACIAS de antemano y perdona las molestias.
Mi problema es que tengo dos tablas: ARTÍCULOS COMPRADOS Y ARTICULOC VENDIDOS y que tienen 5 columnas que son iguales, todas situadas en el mismo orden y con el misnmo tipo de datos como indica Access. Pero tengo que hacer que elegido en una columna (dicho valor debe obtenerse de una consulta a la otra tabla) entonces el resto de las columnas se actualicen automáticamente con el valor que le corresponde en la otra tabla según ese valor elegido y después borrar ese registro en la tabla origen, es decir, hacer una transferencia de tabla comprados a vendidos.
GRACIAS de antemano y perdona las molestias.
1 Respuesta
Respuesta de sramos
1
En primer lugar, me da la impresión de que tienes un problema de diseño en tus tablas. ¿No te sería más fácil tener una sola tabla con los artículos comprados y vendidos? A la estructura actual sólo tendrías que añadirle un campos que llevase los valores 'C' o 'V' en función de si el contenido de la fila es una compra o una venta. Esto te facilitarís muchísimo la realización de las consultas de tu aplicación.
Si realmente necesitas tener la información en las dos tablas, lo que tienes que hacer es una consulta de actualización que realice lo que indicas, es decir, con una instrucción UPDATE.
La verdad que no entiendo bien en qué consiste esta acutalización, por lo que no te puedo ayudar más en aclararte lo que debe hacer exactamente tu consulta de actualización.
Te recomiendo que aprendas un poco sobre diseño de bases de datos antes de trabajar con access, te ayudará muchísimo en la comprensión de esta herramienta, y a hacer un buen uso de ella.
Si realmente necesitas tener la información en las dos tablas, lo que tienes que hacer es una consulta de actualización que realice lo que indicas, es decir, con una instrucción UPDATE.
La verdad que no entiendo bien en qué consiste esta acutalización, por lo que no te puedo ayudar más en aclararte lo que debe hacer exactamente tu consulta de actualización.
Te recomiendo que aprendas un poco sobre diseño de bases de datos antes de trabajar con access, te ayudará muchísimo en la comprensión de esta herramienta, y a hacer un buen uso de ella.
Creo que debí explicarme mejor, lo siento.
Tengo que presentar un trabajo y lo estoy haciendo sobre una tienda. Necesito guardar los datos referentes a los artículos comprados y a los vendidos.
ARTI_COMP--- ref, descripcion, precio_compra
ARTI_VEND---- ref, descripcion, precio_compra, precio_venta,cliente
En un principio pensé lo mismo que tu, colocar un campo lógico si/no que me indique si un articulo está vendido o no.
Pero pensé que seria mejor hacer dos tablas, de esa forma podría trabajar mejor, diferenciaría correctamente el estado de cada producto y llegado el momento guardar los artículos vendidos y quitarlos de la BD para que no ocupe mucho sitio ( quizás todas estas razones sean erróneas y no merezca la pena hacer esas dos trablas).
Otra razón es porque en los art_vendidos necesito tener un enlace con la tabla de facturas_emitidas y creo que al estar relacionadas ambas tablas ( relación 1 - varios ), el campo que las une debe ser introducido obligatoriamente para evitar tener artículos vendidos y no saber cual es la factura en la que está. Pero no puedo poner el nº de la factura ( en ese campo que las relaciona) de los artículos comprados y que no he vendido. Es por eso que pensé en tablas distintas.
Por favor indicame si me equivoco y como puedo arreglarlo, si está mal el diseño,...
De todas formas, gracias por lo de la instrucción Update, aun no la he mirado pero lo voy a hacer ahora mismo.
Tengo que presentar un trabajo y lo estoy haciendo sobre una tienda. Necesito guardar los datos referentes a los artículos comprados y a los vendidos.
ARTI_COMP--- ref, descripcion, precio_compra
ARTI_VEND---- ref, descripcion, precio_compra, precio_venta,cliente
En un principio pensé lo mismo que tu, colocar un campo lógico si/no que me indique si un articulo está vendido o no.
Pero pensé que seria mejor hacer dos tablas, de esa forma podría trabajar mejor, diferenciaría correctamente el estado de cada producto y llegado el momento guardar los artículos vendidos y quitarlos de la BD para que no ocupe mucho sitio ( quizás todas estas razones sean erróneas y no merezca la pena hacer esas dos trablas).
Otra razón es porque en los art_vendidos necesito tener un enlace con la tabla de facturas_emitidas y creo que al estar relacionadas ambas tablas ( relación 1 - varios ), el campo que las une debe ser introducido obligatoriamente para evitar tener artículos vendidos y no saber cual es la factura en la que está. Pero no puedo poner el nº de la factura ( en ese campo que las relaciona) de los artículos comprados y que no he vendido. Es por eso que pensé en tablas distintas.
Por favor indicame si me equivoco y como puedo arreglarlo, si está mal el diseño,...
De todas formas, gracias por lo de la instrucción Update, aun no la he mirado pero lo voy a hacer ahora mismo.
Yo siempre he puesto los movimientos es una sola tabla, y con un campo los he diferenciado. Y allí tratado también los movimientos correspondientes a devolución de compras, devolución de ventas, regularizaciones de stock, regalos, o cualquier otro tipo de movimiento. Esto te da mucha más flexibilidad a tu aplicación. Fíjate, en este caso que acabo de comentar, deberías hacer una tabla para cada tipo de movimiento.
Yo la verdad que veo más sencillo el desarrollo con una sola tabla. Sólo lo he dividido en varias en casos extremos en los que los movimientos superaban con creces el millón de filas anual, y solo por temas de rendimiento.
En cuanto a la factura no hay problemas, si tienes relacionada la tabla de cabeceras de factura con la de líneas de factura (1:N), y la de artículos con la de líneas de factura (1:N).
Un saludo
Salvador Ramos
www.helpdna.net (información sobre SQL Server, Visual Basic, ...)
Yo la verdad que veo más sencillo el desarrollo con una sola tabla. Sólo lo he dividido en varias en casos extremos en los que los movimientos superaban con creces el millón de filas anual, y solo por temas de rendimiento.
En cuanto a la factura no hay problemas, si tienes relacionada la tabla de cabeceras de factura con la de líneas de factura (1:N), y la de artículos con la de líneas de factura (1:N).
Un saludo
Salvador Ramos
www.helpdna.net (información sobre SQL Server, Visual Basic, ...)
