Guía rápida para usuarios de Crystal Reports (3ª parte) (reeditado)

Bien, vamos con la parte más interesante. Por lo menos eso creo yo; si estas cosas me las hubiera dicho alguien antes de ponerme a pelearme con ello hubiera ahorrado un tiempo valiosísimo, que en lugar de haberlo desperdiciado comiéndome el coco hubiera empleado en… en… bueno, es igual.

Se trata de una serie de consejillos que he ido anotando y recolectando y que he agrupado como he podido. Espero que os sean de utilidad.

1.- Una cuestión de diseño: si tenéis que pegar cuadritos de manera que queden lo mejor ajustados posible, es mucho mejor que optéis por dibujar un cuadro grande y dividirlo con líneas. El diseñador es malísimo y ajustar cuadros contiguos para que se alineen perfectamente puede provocar irritacion en vuestros ojos, os lo aseguro. En general toda operación de alineación de elementos en el diseñador es desastrosa.

2.- El origen de los datos: dos posibilidades bastante interesantes con las que yo he trabajado: tablas estáticas y XML. La primera opción es bastante interesante si la red en la que estáis trabajando será la que se utilizará finalmente en la implantación de la aplicación, porque como migréis a otro servidor de base de datos la aplicación CR no encontrará las tablas, las tendréis que volver a cargar y se os borrarán todos aquellos campos que pintábais en el informe, con lo cual tendréis que volver a trabajar.
Es por esto por lo que propongo la segunda opción. Con esta opción la fuente de datos es un objeto ADO, que carga un XML con la estructura de los datos que va a manejar el informe. Con esto se independiza de todo lo demás: servidor, login, usuario etc, para quedarse con lo que realmente le interesa al informe: la estructura de los datos que va a cargar. La mejor idea es construir un procedimiento almacenado (pl/sql) que nos devuelva sólo y exclusivamente aquellos datos con los que vamos a trabajar en el informe (así no tendremos que hacer join de tablas ni nada de eso🙂 ); crear un objeto XML con Visual Studio y arrastrar el pl/sql que deseamos. Después establecemos como origen de datos en el informe tal fichero xml y ya está. Así de fácil.

3.- Si optáis aun así por la creación de varias tablas u os veis obligados a, de una u otra manera utilizar varias tablas en el informe, no os olvidéis de revisar su vinculación en la solapa correspondiente del Asistente de Base de Datos. Normalmente aquí el CR hace bastante bien su trabajo, pero no es omnipotente y a veces se puede confundir si los nombres de los campos son un tanto ambiguos.

4.- A colación de esto último, por defecto CR vincula las tablas con un join natural (inner join); si deseáis un join a izquierdas (para que si encuentra un nulo en un campo de unión no deje el informe el blanco y, en lugar de eso, rellene hasta donde pueda) haced clic derecho sobre el vínculo y en la opción correspondiente a propiedades del vínculo podréis jugar un poco con la vinculación: natural, a izuierdas, de igualdad, desigualdad estricta o no… etc.

5.- A veces se cambian las fuentes de datos de un informe quedan algunos ‘residuos’, como por ejemplo si existe por ahí alguna consulta a la que obedece la generación del informe (un select, vamos; el asistente de consultas). Para evitar este doloroso quebradero y no perdáis demasiado tiempo, PRIMERO borrad la consulta del Asistente de consultas y DESPUÉS eliminad la fuente de datos, en este orden. No es necesario que borréis a mano los campos que aparecían en el informe; el solito se encarga de hacerlo (de ahí el problema de migración de servidores de bases de datos que comentaba en el punto 2).

6.-Cuando se inserta en la sección ‘Detalles’ algún campo de la fuente de datos, automáticamente en la cabecera aparece el nombre del campo subrayado. Esto se puede cambiar, eliminar, etc. Si se elimina el campo, desaparece su cabecera.

7.- Os puede ocurrir que no encuentre el informe al ejecutar (debug) el programa. Esto se soluciona copiando la última versión del fichero .rpt en el directorio bin de la solución, donde se genera el ejecutable. No olvidéis, si es este el caso, copiar la última versión del informe en este directorio o, lógicamente, no veréis los cambios.

8.- Un detalle importante: a veces, sobre todo en la creación de subinformes, como veremos luego, y en su vinculación con el padre, necesitaremos que aparezcan campos en el informe, pero “invisibles”. Nota, listillos: CR no maneja el atributo Visible=false en los controles que se introducen en el informe. Así que nos conformaremos con una solución mucho más arcaica pero eficiente: pintar los campos que deben estar presentes pero no verse del mismo color que el fondo del papel; habitualmente, blanco, lógico.

9.- Ojo al crear campos de parámetro en el informe: el tipo con que los declaráis es importante. Si luego intentáis en el Asistente de Consultas comparar este parámetro con un campo de la fuente de datos y no coinciden los tipos no aparecerá (como parece obvio; no podemos comparar un datetime con un numeric, por ejemplo).

Continuará…

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s