Al momento de configurar un reporte de word y necesito agregar mas de un origen de datos como utilizo los campos PK y FK o que utilidad tienen? |
Es bien fácil. Supongamos que tenes 2 datasources:
Lo que buscamos es un documento de word que te muestre cada rol y dentro una tabla con los usuarios que tienen dicho rol. Por lo tanto el datasource PRINCIPAL será Roles. Ahora, en la configuración de cada datasource tendrías que poner:
Solo una última aclaración, es posible que el join sea con 2 o mas campos, y en este caso, simplemente pondrías los campos separados por "," y en orden, tanto en PK como en FK. Podes ver la descripción de estos al poner el mouse sobre los textboxes. EjemploEdit: Te estoy adjuntando un link para un archivo de word que te permitirá ver como funciona esto y para que puede servir: http://sdrv.ms/ZwNTgP Este archivo está hecho para funcionar con Oracle, porque todos los campos están en mayúscula, si queres que te funcione con SqlServer solo tenes que poner el mismo casing que está en la base de Sql y listo! Si tenes la base de desarrollo, solo tenes que ir al archivo, descargarlo y subirlo al reporte que ya está creado con el código prueba, luego te pasas a la compañía Aseinfo Guatemala y lo ejecutas sin llenar filtros y verás el resultado. Si no tenes acceso a una base de desarrollo podes insertarlo con el siguiente script (Sql Server):
OJO No se te olvide que si estás en Oracle, los campos que pones en el word deben ir en mayúsculas, porque así los regresa Oracle. Por que razón el parámetro de la consulta no funciona, es decir en una prueba tengo lo siguiente:
esta configuración me da un error que dice ORA-00904: "EXP_CODIGO_ALTERNATIVO": invalid identifier. De igual forma si utilizo "EMP_CODIGO". El problema es que estas usandolo mal. Has puesto nombres de tablas y no de vistas o de SP como es lo recomendado. Esto responde a que los filtros se aplican en TODAS las datasources, por lo que si un campo no existe en la otra fallará... Esto no es un bug, funciona así por diseño, ya que no queremos estar filtrando en memoria TODA la tabla secundaria, sino que lo ideal es que se haga en la base de datos Supongo tambien que solo podrás utilizar los campos que se encuentran en la principal, ya que, realice una prueba y un campo que solo existe en el secundario no se muestra y uno que solo existe en el primario si. Si es asi entonces el secundario solo sirve para filtrar al primario? Es que el secundario sirve para detalles. En que escenario lo queres usar? Yo cree mi propio escenario de prueba, no es un requerimiento, es mas, como conocimiento debido a que me ha tocado capacitar y no le encuentro la escencia de dicha funcionalidad. 1
Funcionó gracias. Para ampliar un poco el datasource secundario(s) debe tener una referencia como mínimo en el principal para que funcione, si no puede dar un error. Si lo vemos de otra manera un hijo (secundario) debe tener padre (primario) pero un padre no necesariamente tiene que tener hijos. Autor: Sabanito. 1
Esto es así porque en memoria se crea un FK y por lo tanto no pueden haber huérfanos! :) 1
otro punto es que al querer mostrar los campos del secundario hay que hacer referencia al nombre del origen de datos. Por ejemplo:
showing 5 of 8
show all
|
En el datasource principal, los campos PK y FK se dejan vacíos. En el(los) datasource(s) secundarios, el "campo PK" tiene el nombre de una columna en el datasource principal que representa el código de enlace entre los 2 datasources. Y el "campo FK" tiene el nombre de una columna del datasource secundario, que corresponde con el "campo PK" del datasource principal. (Son las columnas que pondrías en la cláusula ON del JOIN entre los dos datasources) |
Jimy, no se te olvide marcar la respuesta que te ayudó a resolver tu problema!