Error RARÍSIMO.

[Martín E. Lezama]

Muchachos:

Estoy teniendo un error muy raro en reportes. Estoy trabajando con VFP 9.0. Ahora, me suena a que esto es un error DE VISUAL FOXPRO, no sé si lo habrán corregido en algún service pack y no estoy enterado.

El tema es el siguiente. Yo creo un DBF temporario, para efectuar listados (todos mis listados se crean a una tabla temporaria). Supongamos que la llamamos tabla1. Supongamos que en esa tabla tengo un campo llamado campo1.

Entonces, mis dos siguientes órdenes son:

SELECT tabla1

REPORT FORM mireporte.frx NOCONSOLE NOWAIT TO PRINTER PROMPT

Ahora bien, cuando larga el reporte me dice

"No se encuentra la variable campo1".

Yo verifiqué y veo que el campo EXISTE. Ahora bien, cuando rastreo más profundamente, lo que veo que sucede es QUE SE CAMBIA DE ÁREA DE TRABAJO.

¿Por qué puede suceder esto, si mi orden INMEDIATA ANTERIOR al report form es, justamente, posicionate en la tabla correspondiente?

Saludos.

Martín.

[Jairo Miranda]

Puede ser un bug en fox, parece ser que se pierde el cursor , yo lo que hago es un :

Select tabla 

browse timeout 000000.1

report  form reporte prev 

y listo 

Si alguien tiene una mejor idea ??

Jm

[Martín E. Lezama]

Sí, totalmente, pierde el área de trabajo ja. Me vuelve loco, me sucede con algunos listados y con otros no, pero siempre chequeé y los campos estaban, ya me está sacando canas verdes jajaja...

Voy a probar con tu consejo, Jairo, gracias!

[Patricio Muñoz]

Has revisado si tienes alguna tabla en el entorno de datos del informe?

Bendiciones

--

Patricio Muñoz

Pro&Tech

Analista en Sistemas

[Martín E. Lezama]

Yo antes pensaba que podía venir por ciertos timers que yo tenía, en el formulario principal. Esos timers te actualizaban fecha y hora en la barra de tareas de mi sistema, más una especie de semáforo que tiene cada módulo con los cinco puntos "calientes", digámosle. Claro, obviamente, para actualizar eso (que lo hacía cada 2 o 3 segundos, no recuerdo a cuánto había puesto el timer) tenía que disparar consultas. Pero lo raro es que cada formulario está con sesión de datos PRIVADA, o sea... no debería afectar ya que cada uno de los procesos lo hace en un entorno de datos completamente distinto. Pero ante la duda que viniese por ahí, le saqué el "refresh", el reloj y todo para que no jodiera. Ahora, si los puedo volver a poner estaría fantástico, mi panel de comandos andaba bárbaro hasta que me topé con esto jajaja.

El martes, 1 de diciembre de 2015, 17:16:33 (UTC-3), Jairo Miranda escribió:

[Martín E. Lezama]

No no, nunca. En mi sistema, por ejemplo, si el usuario tiene abiertas dos ventanas, y ambas en el mismo listador, AMBAS tratarían de crear el mismo DBF, y te daría error, entonces, yo lo que hago es tener carpetas temp, temp1, temp2, temp3 dependientes de la carpeta de mi sistema en cada disco local, y si se encuentra que tiene la misma tabla en la carpeta temp trata de eliminarla. Si no puede, es porque está abierta, entonces lo que hace es crear (si es que no existe) otra carpeta temporaria y dentro de esa carpeta generar la tabla.

Entonces, como las tablas que utilizo para los reportes pueden estar alojadas en distintas ubicaciones del disco y no en un lugar fijo, nunca le pongo ninguna tabla al entorno de datos de los reportes.

Abrazo, mi amigo!

[Antonio Meza]

Y en vez de crear tanta carpeta y tabla temporal no es mas sencillo solo usar Cursores? y que los cursores los uses en tus reportes y no las tablas temporales, así evitas a demás que tengas problemas con tu timer.

saludos

Antonio Meza

[Martín E. Lezama]

Mirá, se puede hacer de ambas maneras. Yo, en líneas generales, siempre los prefiero en tablas físicas y no en cursores. Más que nada, porque cuando tengo que buscar algún problema en X listado (suelo trabajar, además de programador, como asesor administrativo en mis clientes), me sirve tener el temporario generado, para repasarlo después y ver por qué falla tal o cual listado, por qué X registro no fue incluido en una cláusula SELECT determinada. Siempre me fue de mucha más utilidad (y ni hablar cuando utilizo el programa compilado en EXES y no el código fuente en los clientes) saber cómo se llama un temporario determinado que tira tal informe. Por ejemplo, la orden de pago de sueldos se guarda en un temporario "opsueldo.dbf" en la carpeta TEMP. Entonces, cuando voy a buscar cuáles registros tenía esa OP de sueldos, y por qué, por ejemplo, no listó un embargo al empleado Juan Pérez que DEBIÓ estar en esa Orden de Pago y no salió, tener el temporario en un lugar físico determinado y con un nombre identificable te ayuda mucho.

Ese es el motivo también de por qué utilizo varias carpetas temp en lugar de, por ejemplo, utilizar funciones para generar un nombre único de archivo. Eso lo podría hacer. Pero después tengo que buscar mi OP de sueldos entre un montón de archivos que se llaman Q0137423/4/5/6 y tengo que andar abriendo uno por uno hasta que encuentro el que realmente buscaba jaja.

No sé, son distintas formas de trabajo. Viste que en programación no existe una única forma de hacer las cosas, sino dos o tres, y uno se va decantando a través del tiempo por una u otra manera. Antes trabajaba con los archivos temporarios con nombres únicos. Opté por esta solución porque noté que me ahorraba muchísimo tiempo de debugging cuando me topaba con errores, o con listadores que se comportaban de un modo "extraño" y los muy guachos perdían registros. En realidad, llamarlos de esta manera me permitía, muchas veces, chantárselos en la jeta a los clientes y mostrarle "mirá, chabón, este embargo no te lo trae en la OP porque vos lo marcaste como cerrado, y si vos cerraste un embargo, ¿cómo querés que el sistema lo pague?" y que los clientes no te lo puedan discutir jaja.

Vos pensá que para muchos clientes nosotros somos personajes tan esotéricos como los alquimistas muejeje. Entonces, cuando les "falla" algo, no se ponen a pensar "dónde habré metido mal los dedos yo" si no "este sistema de m... no anda" ja. :D

[Antonio Meza]

Un problema lo puedes resolver de mil maneras para morir jajajaj (me acorde del programa feo ese!!! jaja) 

Pero hay técnicas básicas de programación (buenas practicas) y en lo personal remplazaría tus temporales por cursores y agregaría un LOG o historial de procesos para solventar tu necesidad de poder ver que paso y en su caso demostrarle al cliente.

saludos

Antonio Meza

[Martín E. Lezama]

Puede ser. Igualmente, vos pensá que uno a veces trabaja desde hace muchísimo tiempo (en mi caso, desde Clipper Summer 87). Entonces, parte de mi código fuente viene desde cuando empecé con Clipper a desarrollar a los 17 años, con las herramientas que tenía en ese entonces el Clipper, y fui adaptando parte del código al migrar a VFP pero hay partes que quedaron porque así funcionaban bien. Hoy en día, con 45 y ya 28 escritos de código fuente, hay cosas que la verdad... tenés que tener razones muy valederas para meterte a tocarlas, tenés que tener tiempo para ponerte a pensar cuál sería la mejor alternativa para el reemplazo... y aparte, fundamental, tenés que tener GANAS para hacerlo ja. Hoy por hoy, a mí me sucede que no me desvela la programación como antes. Que me cuesta encontrar incentivos para seguir trabajando de esto, que cuando los tengo (por ejemplo, agregarle a mi sistema X módulo para cubrir tal o cual mercado que nunca estuvo contemplado) me engancho, y que cuando no, realmente me aburro, estoy trabajando pero todo el tiempo pensando "¿cuándo podré llegar a casa así sigo trabajando en mi guitarra?" (me estoy fabricando una eléctrica de 12 cuerdas).

Me sucede eso porque, digamos, hoy en día me siento muy metido en la rutina de las cosas. Como que cada día es indefectiblemente igual al anterior, y antes, por el contrario, me pasaba que cada día descubría nuevos incentivos... yo qué sé, tendré que plantearme quizás a conseguir nuevos clientes, o nuevos desafíos con los que tengo, por ejemplo desarrollar web, para volverle a encontrar el gustito a la cosa.

Y además, nunca te olvides, Antonio, nuestra frase de cabecera.

"¿Anda? Fenómeno, entonces no toques" Jajajaja

[Antonio Meza]

Eso si, lo que funciona así déjalo jajaj

También empece con Clipper de ahí a VFP 6, 7 y 9, la 10 ya no migre porque ya no la sacaron jajajaj

no queda de otra que darle porque la noche es larga jajaja

saludos!!!

[integral]

Estimado amigo MARTIN .

Quien te escribe cuenta con dos años mas y empeze a programar con DBASE III PLUS, CLIPPER, FOXBASE y Foxpro para D.o.s. 2.6  y casi todas las versioens de VFP.

 

Pues bien, Luego de venir utilizando VFP por mas de 8 años he podido encontrar algunos detalles importantes a considerar para no tener problemas y esto nos haga pensar que son BUG de VFP.

En tu caso especifico te recomiendo lo siguiente :

1) Hacer un Backup de la tabla del problema y renombrar el campo1 

2) Si sigue el problema deberas utilizar el comando AGAIN o ALIAS y utilizarlo en el cursor creado en forma temporal. 

Espero con ello se resuelva el problema.

Saludos,

INTEGRAL

[Fernando D. Bozzo]

Hola Martín:

Lei todos tus comentarios y en parte te entiendo, además de que somos de la misma época y pasamos más o menos por las mismas herramientas (dBase, FoxBase, FoxPro, etc).

Supongo que que por la forma de ser de cada uno y del tipo de trabajo que cada uno busque o encuentre (tener clientes propios -vs- trabajo por cuenta ajena para otras empresas), puede influir en mantener la ilusión y el gusto por programar (entre otros) o que de pronto comience a parecer aburrido y monótono.

En parte me identifico con algunas cosas que comentás, pero me pasó muchas veces que ante la rutina y el aburrimiento por lo mismo o las limitaciones del momento, intentaba aprender o mejorar cosas, o de pronto trabajar en algún proyecto que me permita salir un poco de esos límites o que me sirva para mejorar otras cosas. Fruto de estas limitaciones temporales y ganas de mejora fue lo que me motivó a hacer algunos proyectos abiertos como el de Controles Comunes (estilo XP, VFP 6) hace muchos años, o el más reciente, FoxBin2Prg, para poder trabajar con programas de Control de Código Fuente y poder mejorar el flujo de programación y las posibilidades de poder trabajar en paralelo en varias características para agilizar los desarrollos. El primero lo hice en solitario más como un reto técnico que otra cosa, mientras que el segundo fue motivado por una necesidad real y del que disfruté mucho haciéndolo y compartiendo el feedback increíble de programadores de todo el mundo mientras lo hacía. Eso si es motivante.

Sobre lo que comentás de encontrar los incentivos, pues sí, a veces cuesta, y por eso hay que ver otros lenguajes, probar otras cosas y agrandar "la caja de herramientas" que tenemos para solucionar o afrontar nuevos problemas y retos. Una de las cosas que siempre te van a servir en cualquier lenguaje, y por lo tanto es una buena inversión de tiempo, es aprender de las buenas prácticas que tanto comentamos en el foro, lo que ayuda a evitar problemas que fueron detectados, algunos, hace muchos años, y además de esto, el usar un programa para control de código fuente, a lo que tantos programadores escapan :), por creer que es perder tiempo o que es complicado, cuando realmente te permite no solo ganar tiempo, sino poder trabajar con más seguridad, revisar el historial de cambios de tus aplicaciones, compartir código, arreglar cosas más rápido o trabajar en varias mejoras o peticiones por separado pudiendo elegir que sacar primero o que dejar inmovilizado.
Otra herramienta muy útil para mejorar desarrollos es el Unit Testing, cuyos fundamentos te pueden servir en cualquier lenguaje y donde bien usado podés ganar hasta cientos o miles de horas de pruebas, dependiendo del tamaño del proyecto y de la frecuencia de los cambios. En el caso de VFP tenemos el FoxUnit, pero cada lenguaje tiene su framework específico, NUnit para .Net, JUnit para Java, PLUnit para PL/SQL, etc)

Respecto de lo último que comentás sobre los problemas que tenés con algunos reportes y areas de trabajo, algo que puede influir en esto es la llamada a métodos que hagan consultas a otras tablas (y por tanto en otras áreas de trabajo) o el uso de timers, que son mucho más complicados de depurar, ya que estos a veces ocurren en medio de un proceso (si se usa DOEVENTS) pero principalmente en situaciones de espera, y a veces interfieren en la sesión de datos aunque sea privada, y casualmente muchas veces estos problemas tienen que ver con no usar buenas prácticas de programación.

Por ejemplo, bajo estas estas prácticas un módulo y los métodos deben estar encapsulados para no afectar a otros métodos (o incluso entre sí), por lo que usar control de errores (try/catch) es una de las recomendaciones, restaurar el área de trabajo al finalizar es otra (te asegurás de que a otro módulo no se la cambies), o de usar ALIAS para que no coincidan los nombres de las tablas o de usar sesión privada de datos o de parametrizar y liberar recursos (variables, tablas, etc) correctamente.

Me salió un poco largo al final, creo que me inspiraste a escribir :-)


Saludos.-

[Gregorio Nava]

Agregale el alias al campo tabla1.campo1

[Martín E. Lezama]

No, no, no me entendiste. La tabla utilizada es una tabla temporaria.

O sea, por ejemplo, esto viene de un comando similar a este.

SELECT facturas.campo1, facturas.campo2, facturas.campo3, ;

       IIF(ISNULL(clientes.razsocial),SPACE(60),clientes.razsocial) AS razsocial ;
FROM facturas
       LEFT JOIN clientes ;
             ON facturas.codclie = clientes.codclie ;
WHERE BETWEEN(facturas.fechaemi,{01/11/2015},{30/11/2015}) ;

   AND EMPTY(facturas.anulado) ;
INTO TABLE c:\sistema\temp\tabla1

Y yo listo el campo1 de esa tabla1. Así es que no viene por podredumbre de las tablas ni nada por el estilo. Lo que puse fue a modo de ejemplo, por ejemplo cómo lo haría para listar un IVA Ventas.

[Martín E. Lezama]

Muy buenas tus observaciones Fernando!!!

Voy a ponerle un poquitito de atención en estos días, que como se vienen las fiestas, suele haber poco laburo, a ver si consigo utilizar alguna de las cosas que me recomendás.

Te mando un abrazo grande, gracias por el tiempo que le dedicaste a mi humilde problema, amigazo. ;-)

[Martín E. Lezama]

Sí. Suelo esquivarle ponerle el alias al campo porque muchas veces un mismo formato de reporte lo utilizo en más de un listado, en donde los filtros son distintos.

Pero esa sería una buena alternativa para subsanar el tema. Muchas gracias! No se me había ocurrido porque como nunca la uso, no la tuve ni siquiera en cuenta.

[Fernando D. Bozzo]

Hola Martín:

Primero, algo que no tiene que ver con la solución, pero sí con la optimización de tu SQL, y es que te conviene usar lenguaje SQL lo más posible con la menor cantidad de instrucciones no-SQL que hagan lo mismo.
En tu caso, la consulta que pusiste sería así:

SELECT facturas.campo1, facturas.campo2, facturas.campo3, ;

       NVL(clientes.razsocial,SPACE(60)) AS razsocial ;

FROM facturas
       LEFT JOIN clientes ;
             ON facturas.codclie = clientes.codclie ;

WHERE facturas.fechaemi BETWEEN {01/11/2015} AND {30/11/2015} ;

   AND EMPTY(facturas.anulado) ;
INTO TABLE c:\sistema\temp\tabla1

Luego, sobre el problema que comentás, no me consta que VFP pierda ningún área de trabajo, si no estaría reportado hace mucho tiempo y por mucha gente, ya que todo el mundo usa áreas de trabajo e incluso sesiones.

¿El reporte que usás tiene sesión de datos predeterminada o privada?

1) Si es predeterminada, asegurate de comprobar que la tabla está abierta y seleccionada, con algo como esto:

IF USED("tabla1")
   SELECT Tabla1
ELSE
   SELECT 0
   USE Tabla1 SHARED AGAIN NOUPDATE
ENDIF

* Aquí el reporte

2) Si no es predeterminada y es sesión privada, entonces probá a abrir la tabla con un alias que no sea Tabla1 y en el reporte evitá usar tabla1.campo como nomenclatura de los campos del reporte. En su lugar usá solamente el nombre del campo, para evitar la dependencia del nombre de la tabla.


Saludos.-

[Martín E. Lezama]

Está muy buena la solución de la sintaxis je. Es verdad, yo muchas veces he tenido que cambiar cierta sintaxis de FOX cuando trabajaba en MySQL o en SQLServer. Ya empiezo a practicar con ese formato porque el IIF(ISNULL(blablabla)) lo tengo por todos lados :D

Sobre lo siguiente:

Es JUSTAMENTE LO QUE HAGO

Una vez que hago el SELECT lo primero que hago es hacer

SELECT tabla1

REPORT FORM blablabla.

Los reportes SIEMPRE usan la sesión predeterminada de datos, y evito ponerle tablas al entorno de datos del reporte. Ahora bien, no es que se "pierda" el área de trabajo. Te explico de nuevo la falla.

1) Hago el SELECT-SQL

2) Me posiciono en la tabla (SELECT tabla1)

3) Tiro el reporte.

4) Me da error.

5) Puteo. :-D

6) Voy y me fijo y resulta que está parado en OTRA área de trabajo, y no en el área en el que le pedí EXPRESAMENTE que se posicione con el punto 2. O sea, la tabla EXISTE, el SELECT la creó (de hecho, un SELECT-SQL tirado INTO TABLE o INTO DBF siempre genera una tabla, a diferencia de un SELECT tirado a un array, por ejemplo, en donde si no hay registros no te crea el array. Los select a tabla te generan la tabla, aunque sea que no haya información (te la genera con 0 registros).

OJO, la tabla no se llama tabla1, ni el campo que me da fallas, campo1. Eso lo puse para hacer más fácil el ejemplo.

Por ejemplo, en el caso que más me sucede, la tabla se llama opsueldo (orden de pago de sueldos). Pero también me sucede en certepp1 (certificados de entrega de elementos de protección personal). Ahora voy a revisar los reports por las dudas que no estén configurados ESOS DOS como sesión privada de datos, pero lo dudo, ya que todos los reports los hice a partir de un modelo standard, que siempre estuvo configurado como sesión predeterminada de datos. Aparte, lo raro es que A VECES funciona bien, o sea, las fallas me surgen ALEATORIAMENTE, unas veces imprime, otras veces no. Y resulta que evidentemente, a lo que a veces me da bola y a veces no es a mi paso 2, cuando le digo "Parate acá, mierda carajo" :-D :-D :-D

Abrazo, Fernando!!!

[Fernando D. Bozzo]

¿Por casualidad estás usando timers? Porque fuera de lo comentado solo se me ocurren 2 casos por los que se pueda perder el área de trabajo:

1) Porque se usa un timer que hace algún tipo de acceso a datos (SQL, SELECT, etc) o que crea algún cursor

2) Porque desde el reporte se llame a alguna UDF, por ejemplo de cálculo, que para hacer ese cálculo haga lo mismo, es decir, algún acceso de datos o creación de cursor.

[Martín E. Lezama]

Claro, originalmente TENÍA timers en la barra del form principal del sistema. El timer que tiraba fecha y hora. Lo saqué para ver si por ese lado venía el asunto pero no.

No, no estoy usando ninguna UDF. En líneas generales siempre las UDF las utilizo a la hora del SELECT, para que el REPORT sea lo más plano posible.

[Fernando D. Bozzo]

Ah, y olvidaba dos casos más:

3) Que ocurra algún error que sea atrapado por una rutina de manejo de errores que haga algún acceso a datos o creación de cursor, y que en vez de mostrar el error lo ignore.

4) Que estés haciendo algún SELECT (alias) en un EVENTO del form o de algún control como el Activate/Deactivate/GotFocus/LostFocus/etc. Aunque cualquiera de estas es una mala práctica, sobre todo si no se usa con control de errores, es una práctica bastante extendida entre muchos programadores, y es lo que la hace más difícil de depurar.

Te dejo una idea de depuración que podría servirte para encontrar el problema:

1) Abri el depurador (DEBUG en ventana de comandos) y en la ventana "Watch" agregá la función ALIAS(). No cierres la ventana DEBUG

2) Justo antes del SELECT-SQL poné un SET STEP ON

3) Ejecutá tu programa (con la ventana DEBUG abierta, aunque no esté encima) hasta que salte el SET STEP
4) Nuevamente dentro de la ventana Watch, ponele una interrupción a ALIAS() y comprobá que muestra el alias correcto

5) Dale al Play para que continúe la ejecución completa y haga el reporte

Cualquier cambio en el área de trabajo que haya, se debería detener justo en ese punto con el depurador abierto y deberías poder encontrar el problema en un minuto.

Comentame qué tal fue.

[Martín E. Lezama]

Me olvidaba comentarte algo.

Cuando pongo el SET STEP y hago el DEBUG.... NUNCA ME DA LA FALLA, EL MUY HDP. :-D

Obviamente, al cliente no se lo puedo dejar con el SET STEP puesto, pero hasta ahora fue la mejor solución jajajajaja.

[Martín E. Lezama]

La 4... soy muy cuidadoso con eso. En esos métodos trato de ni siquiera poner código, si lo puedo evitar. Generalmente uso para poner código los métodos BeforeOpenTables y OpenTables del entorno de datos, el Init, el Load y el Unload. En general trato de que los forms no hagan nada en el Activate o Deactivate etc. etc., tengo, por ejemplo, un botón que te permite dar de alta registros en maestro y después volver a la facturación (pongamos) y utilizar esos registros dados de alta, pero no utilizo el activate para eso, porque sería una locura. El ÚNICO código que puede llegar a estar utilizando en el Activate es poner en negrita la fuente del objeto en el que estés parado, a lo sumo, como para indicarte más precisamente en dónde te quedaste.

Después... la rutina de error, la tiene y graba los errores en una tabla de errores. Pero el tema es que no saltan errores. Ya chequeé el DBF, y en ningún momento tiene un registro de error anterior a eso.

Aparte, son dos líneas LPM.

SELECT mitabla

REPORT FORM mireporte NOCONSOLE NOWAIT TO PRINTER PROMPT

Lo que me extraña es por qué entre una línea y la otra, se cambia de área de trabajo. Y lo peor es que lo hace aleatoriamente. A veces sí y a veces no. Por eso pensé que podía venir de algún bug del VFP 9 que hubiese sido solucionado con algún service pack.

[Martín E. Lezama]

UN PEQUEÑO DETALLE que ahora recuerdo. Estos errores NO ME SUCEDÍAN en VFP 7. Me empezaron a suceder cuando migré el desarrollo a VFP 9.

[Fausto Reyes]

Martin vamos hacer el siguiente ejercicio.
Antes de ejecutar el report  form para imprimir o visualizar el reporte. Posiciona el cursor en un campo text  u otro objeto que cuando coja el focus  no se haga referencia a ninguna tabla ni cursor.  Si es posible agregate  un campo en blanco que no haga nada, solo para fines de prueba y le mandas el focus  a ese campo.
Luego haces tu select cursor temporal del reporte y ejecuta el report  form.

[Fernando D. Bozzo]

Entonces si con SET STEP no te pasa nunca, te conviene registrar toda la información del entorno al momento de producirse el error, como por ejemplo:

- Qué área de trabajo está elegida y con qué ALIAS

- La lista del STACK de ejecución

- Alguna otra información útil

Dependiendo de la tabla que te quede elegida, podrías ver qué hace que se elija esa tabla.

Por ahora no tengo más ideas :)

[Fernando D. Bozzo]

¿Tenés el SP2 instalado? Fijate en la ventana de comandos usando ? VERSION(), que debería devolverte esto:

Visual FoxPro 09.00.0000.5815 for Windows

La parte en negrita debería ser como mínimo 5815. pero podría ser superior (7xxx) si aplicaste los HotFix posteriores (que no son Service Pack!)

Así al menos nos aseguramos de que tenés la versión correcta.


Saludos.-

[Jose Mario]

es que no cambia de area de rabajo. linea en linea

los errores no salen porque son en el report

debe de haber un nombre de campo en el report

por ejemplo tabla1.campo1

o campo1 dentro del report

dentro del report es dificil encontrar un error

es de ir de campo en campo, para encontrarlo

[Jose Mario]

yo que tu lo colocara el report

envialo

[Javier Cabrera]

Ya viste el datasession de tu formset,  o el autoopen o autoclore del reporte?

saludos