Consultas en informes

Cada informe se alimenta sólo de una consulta.
Puedes hacer dos cosas:
a) Hacer una consulta compleja que tenga todo lo que quieres en el informe y formatearlo adecuadamente
b) hacer un informe con subinformes y relacionarlos en el primero. De esta manera cada subinforme tendrá su propia consulta
Es mejor, más potente y rápida la opción b)

Bien, me gusta más la opción b, porque tengo me mostrar mucha y distinta información en el informe. Aunque nunca he hecho subinformes.. Probaré a ver
Muchas gracias

Para darle buen aspecto, maneja bien el encabezado y pie de página y de informe, y el tamaño vertical de los subinformes, si quieres tener una hoja por cada registro con mucha información te puede dar algún problema si se salen de la página.
Suerte

¿Los subinformes tienen que ser verticales? Me interesan horizontales..
Todavía no lo he probado, estoy intentando resolver otro informe: está asociado a la siguiente consulta:
"SELECT meses.Nombre, meses.Número, T_Almeria.Cuota_Obrera AS C_almeria, T_Cadiz.Cuota_Obrera AS C_cadiz
FROM (meses LEFT JOIN T_Almeria ON meses.Número = T_Almeria.Mes_numero) LEFT JOIN T_Cadiz ON meses.Número = T_Cadiz.Mes_numero
WHERE (((T_Almeria.Tipo)="real") AND ((T_Cadiz.Tipo)="real"))
ORDER BY meses.Número;"
Pero me duplica registros, esos LEFT JOIN no son los que me interesarían, pero no consigo cambiarlos.
Lo que me interesaría es: cada registro de la tabla "meses" enlazarlo con los de las otras tablas. Algo así como (meses) LEFT JOIN (todas las demás tablas), pero no sé cómo hacerlo con access.
¿Podrías ayudarme con esto?
Gracias de antemano

El tamaño vertical de los subinformes crece/decrece con el número de registros de cada subinforme, por eso te digo tamaño vertical. Se colocan en horizontal, y tienen una presentación igualmente en horizontal.
Sin conocer los datos de tus tablas, imagino que para la cuestión de duplicidad de registros has de tocar algo en el agrupamiento de los datos de la consulta, o tienes valores duplicados en alguna tabla, o te falta alguna tabla (no veo en el SQL ninguna tabla meses ¿? De la que hablas en el siguiente párrafo). Si Access duplica, o mejor dicho combina, registros se suele deber a alguna causa como esta. Mete la tabla meses
Como te digo, no conozco los valores o el contenido de tus tablas, a primera vista por el SQL de la consulta, tienes valores de Cádiz y Almería. Si las tablas, y los datos, tienen la misma estructura ¿por qué lo tienes en dos tablas?, imagino que tendrá una por cada provincia, ¿por qué no utilizas una única tabla para todas las provincias, añadiendo un campo para almacenar la provincia? Si lo haces con las relaciones adecuadas, te será más fácil estrucuturar tus datos y trabajar con ellos.

[size= small; font-family: Times New Roman]La tabla meses aparece en los LEFT JOIN que copié antes.. Es con la que enlazo cada tabla de provincia. Tengo una para cada provincia, porque la idea es que varios usuarios puedan trabajar a la vez, en la misma bdd, y mientras uno introduce datos de Almería otro lo haga con Cádiz, por ejemplo. Y si fuera la misma tabla, se "machacarían" los datos, ¿no? Al menos eso pensé.. No sé si hay alguna otra manera de hacerlo..[/size]
[size= small; font-family: Times New Roman]Al final he hecho una consulta uniendo la tabla meses con cada provincia, y en otra consulta las he unido todas, no he visto otra solución.[/size]

(Parece que antes no se envió mi respuesta..)
La tabla meses es la que aparece a la izquierda en los LEFT JOIN que copié..
Tengo una tabla para cada provincia, porque la idea es que distintos usuarios usen la misma bdd a la vez, y así mientras uno guarda datos de Almería, otro lo haga con Cádiz, por ejemplo. Si tuviera una única tabla, ¿se "machacarían" los datos unos a otros no? Por eso tengo tantas tablas.
Al final hice una consulta de la tabla meses con cada una de las provincias, y otra consulta globas para unirlas todas, no he visto otra solución..
En relación con las tablas de las provincias: si tuviera una única tabla para todas las provincias, dintinguiéndolas con un código, y según la selección del usuario abriera un único formulario del que cambio la consulta según la selección de provincia, ¿habría problema con los datos si varios usuarios lo tienen abierto a la vez? No sé si me he explicado bien..
Gracias de antemano por todas las respuestas

No se machacan los datos trabajando simultáneamente (en alguna pregunta he respondido esto más en detalle, hace falta una BD en el servidor sólo con las tablas, y otra con los formularios e informes y las tablas vinculadas a la primera en cada equipo en local)
De todas maneras, puedes utilizar la misma tabla, y diferenciar por registro, añadiendo un campo con la provincia y poner por defecto Almería a uno, Granada a otro, etc. La tabla se llama provincia en todas las BD, con lo que te valen todas las consultas entre las bases de datos, y tienes en cada registro la provincia para cuando las agrupes todas juntas.
SELECT ... FROM Almería
SELECT ... FROM Granada
Te vale para todas la BD's SELECT ... FROM Cuotas
Me explico, tienes la tabla Almería
Campo1, Campo2, Campo3
Tienes la tabla Granada
Campo1, Campo2, Campo3
Lo que puedes hacer para facilitarte la vida es tener una sola tabla para estos datos, primero una tabla de provincia y relacionada con esta la tabla de datos, y otra de meses también relacionada, y que la estructura y nombres de las tablas sean iguales para todos los usuarios, por un lado no se liarán al cambiar con los datos de una provincia a otra, y a ti te valdrán las consultas de una BD para todas.
Para ponerlo en red, tienes que tener una BD sólo con las tablas; y una en cada equipo de la red con las consultas, formularios, informes, macros y módulos y las tablas vinculadas a la primera. Con esto consigues que todos trabajen contra los mismos datos.
No corres gran peligro de esta manera, Access bloquea el registro que se está editando, no la tabla, ni la base de datos. Sólo dará un aviso en el caso en el que dos usuarios estén modificando el mismo registro a la vez, pero no pasa nada si son registros distintos, y según me dices uno trabaja con Almería y otro con Granada con lo que no debe suceder que accedan a la vez a modificar la misma cuota de la misma provincia. Yo he tenido 20-30 usuarios trabajando simultáneamente durante varios meses contra una tabla con pocos registros y en un año me ha dado dos o tres avisos, no más.
Pruébalo en tu equipo, pon una BD con las tablas y otros dos con todo lo demás sin las tablas. Las vinculas a estas dos BD's de la primera (vincular, no importar: Archivo > Obtener datos externos > Importar, vincular tablas). Y las abres a la vez en tu propio equipo para ver el efecto que ocurre accediendo a registros distintos y a editar el mismo.
Haz una tabla meses, otra provincias, otra cuotas con el campo de la provincia y los meses (supongo que se llama así) y las relacionas, te facilitará mucho tu labor.
Espero que te sea de ayuda
En alguna respuesta ya he contestado a alguien lo de la base de datos en el servidor y en local, y el acceso simultáneo con más detalle

Suena mucho mejor eso que todo el lío de tablas que tengo ahora mismo.. Pero tengo que terminar lo que tengo pendiente antes de ponerme a cambiarlo todo..
Tengo tres informes independientes, pero con la misma estructura: título de columna=provincias, título de filas=meses. Cada uno con origen en una consulta.
Lo que necesito ahora es mostrar en otro informe esos 3: con titulo de columna=provincias, titulo de filas=meses, y que en la fila de datos de cada mes me aparezcan los 3 registros de los 3 informes. Había pensado utilizar los subinformes, para unir los 3 que ya tengo, pero por lo que estoy probando, no obtengo el resultado que busco.
¿Una consulta de unión con las 3 que tengo será mejor?

Si las tres consultas tienen la misma estructura de salida, es buena solución hacer una UNION para meterlas en un informe, lo que puedes hacer para darle buena presentación es a las consultas que metes en la UNION darle constantes (si te hacen falta, a lo mejor no) para diferenciar los registros que vienen de una y los que vienen de otra, me explico
una consulta que te hace un count por días
otra consulta que te hace un count por semanas
otra consulta que te hace un count por meses,
te pongo sólo esta última con una constante para que lo veas y lo apliques si te parece interesante:
SELECT Count(Tabla1.num) AS CuentaDeCampo, 'Mensual' AS Periodo FROM Tabla1 GROUP BY 'Meses', Month([Fecha]);
Te saldrá la constante "Mensual" para el periodo", y lo podrás personalizar para las otras dos, así podrás entresacar los registros de la UNION a tu gusto (en este caso por periodo)
Alguna vez he utilizado algo parecido a esto y a lo que propones, y lo he visto en informes BD's muy muy potentes de organismos de algún Ministerio. Es hacer algo así
para cada categoría, generar una consulta de salida con un solo campo de texto (concatenando valores de los campos a tu gusto), otro campo que indica la categoría y otro el orden para mostrarlo y luego meter todas en una UNION y sacar esta por un informe.

Sí, el informe me salió bien con la consulta de union de las otras tres.. Muchas gracias.
Estoy pensando ya la manera de hacer el cambio en la BD, para tener una con las tablas de servidor, otra con los formularios y demás en los equipos de los usuarios. Me surge una primera duda: la idea de hacer ese cambio es unificar al máximo mis tablas, identificando los registros con nuevos campos. Pero.. ¿cómo podré pasar los registros de mis tablas actuales (con 15 campos, más o menos) a las nuevas que seguro que tendrán muchos más campos? Cada vez que hecho un copia/pega con varias líneas de una tabla a otra, la estructura de las tablas tenía que ser exactamente igual, por eso me pregunto esto.. que es lo primero con lo que me voy a encontrar.
Otra cosa que estoy intentando ahora es, en un informe, si un valor es negativo, cambiarle de color el texto. Pero el valor está en un "cuadro de texto", y no consigo hacer referencia a él, me da error

Bueno, mi duda sobre copiar los datos de una tabla a otra con más campos, creo que no es nada. Acabo de hacer una prueba, y parece que se copian bien..

Puedes hacerlo simplemente copiando y pegando, pero lo más correcto es que lo hagas sobre unas tablas vacías añadiendo los registros mediante consultas de datos anexados, y poniendo cuidado en el orden en el que lo haces.
Como consejo: hazte todas las consultas de eliminación para borrar todas las tablas en orden (por las relaciones) y todas las consultas de datos anexados para rellenar, las guardas con el número de orden de ejecución en el nombre y así las puedes ejecutar todas seguidas mediante una macro o un módulo.
Yo suelo utilizar en el comienzo del nombre de las consultas QD_..., y QA_... para query delete y query append, por ejemplo QD_001_001, QD_001_002, ... QA_001_001, QA_001_002, ...
y luego las pones en una macro, o en un módulo así:
DoCmd.OpenQuery "QD_001_001"
DoCmd.OpenQuery "QD_001_002"
...
DoCmd.OpenQuery "QA_001_001"
...
Al principio para que no avise utiliza DoCmd. SetWarnings false, y cuando termines de ejecutar las consulta vuelve a ponerlo en true (para evitar desagradable borrados sin darse cuenta)
Espero que te sea de ayuda
Cierra la pregunta si te parece que ya está resuelta, por que me sigue apareciendo como consulta nueva cada post, y me lio con las que tengo pendientes.

Muchas gracias por el consejo, lo haré así. Aunque no entiendo muy bien lo de las consultas de eliminación: una vez que haya añadido los datos en las tablas nuevas con las QA, borraré las tablas antiguas completamente, ¿no?
(Ahora cierro la pregunta. Perdona por el lio. Y muchas gracias por todas las aclaraciones)

Una vez que tengas las tablas (vacías o llenas) lo que tendrás que hacer es volcar los datos.
Lo más cómodo es hacerlo mediante consultas de datos anexados, una para cada tabla que quieras llenar de datos (yo las guardo y les doy un nombre que empieza por QA, de query append, y luego unos números)
El número es por que ha de hacerse por orden, según sean las relaciones de tus tablas.
¿Qué ocurre si las vuelvo a ejecutar? Que corro el riesgo de que se me duplique información en las tablas
Para que esto ocurra la borro antes, mediante una consulta de eliminación para cada tabla (les doy un nombre que empiece por QD, de query delete, e igualmente unos números que me dicen el orden, por la misma cuestión de las relaciones)
Por eso ejecuto las QD, por orden, y luego las QA igualmente por orden, de esta manera me aseguro que no duplicon información:
En tu caso, por ejemplo
QD_001_001 (borro una tabla donde volcaré los datos, la tabla A)
QD_001_002 (borro la tabla B)
QD_001_003 (borro la tabla C)
...
QA_001_001_Almería (vuelco los datos Almería en la tabla C)
QA_001_001_Granada (vuelco los datos de Granada en la tabla C)
QA_001_002_Almería (vuelco los datos de Almería en la tabla B)
QA_001_002_Granada (vuelco los datos de Granada en la tabla B)
QA_001_002_Almería (vuelco los datos de Almería en la tabla A)
QA_001_003_Granada (vuelco los datos de Granada en la tabla A)
Si te das cuenta el orden de llenado (consultas QA) es inverso al de vaciado (consultas QD), esto se debe a las relaciones entre la tablas. Te darás cuenta de ese orden cuando intentes borrar datos (mediante consulta o directamente en la tabla) y Access te diga que no puede borrar por que hay registros relacionados en otra tabla.
Si la estructura de tablas no la ha hecho tu, para averiguar esto de las relaciones, lo puedes ver en la ventana de relaciones de las tablas, o borrando todos los registros a mano (si haces click en el cuadrito donde se juntan los encabezados de filas y columnas seleccionarás toda la tabla) de toda la tabla. En algún momento te dirá que no puede borrar por que existen registros relacionados en la tabla que 'tal' Esto significa que tienes que borrar primero los datos de la tabla 'tal' para borrar los de la primera.
Si consigues borrar todo a mano sin ningún tipo de aviso se debe a dos cosas:
a) Has acertado en el orden --> prueba a borrar en otro orden distinto
b) las relaciones no están bien definidas, habría que dar una vuelta a las relaciones de las tablas haciendo un poco de análisis para tener integridad y consistencia en los datos. Si esto no está bien, puede ser dudosa la información que luego se quiera estudiar.
Lo primero que hago con una BD que caiga en mis manos para analizar es ver las tablas y las relaciones, y muchas veces te llevas sorpresas de tremendas bases de datos sin una sola relación ¿? Eso me dice mucho de como se ha hecho, de lo que se pretende hacer con esta base de datos, si valdrá o no valdrá, y de los riesgos de seguiir utilizandola; generalmente estas bd sin relaciones acaban en unos líos de datos tan grandes que los datos ya no valen para nada.