jgust

The group functionality adds a group header and footer to the outline. The data in the details band will continue to display unless you suppress it from printing.

It is normal for databases to return rows differently depending on how the SQL is put together. If you need a specific order add an Order By clause or a sort to the report. Your best bet is to do an Order By clause. I found inconsistent sorting results in Jasper when it came to spaces and non-ASCII characters.

You are correct. I will also add that you can use "false" as the expression, there is no need for 1==0. I use it in my reports where I have a detailed row (1) to assist me when I need to debug the report.

I've just started seeing those errors. I haven't been able to find the root issue yet. Caused by: java.lang.NoClassDefFoundError: ECD0450004500645158145PDF32SUB323 (wrong name: ECD0450004500645158145PDF32SUB323_8231820df3d06c632f8f2d6dea86758af8bb35b4b8e090a74619f0e8fde361bc) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at net.sf.jasperreports.engine.util.JRClassLoader.loadClass(JRClassLoader.java:378) at net.sf.jasperreports.engine.util.JRClassLoader.loadClassFromBytes(JRClassLoader.java:302) at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadClass(JRAbstractJavaCompiler.java:142) at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadEvaluator(JRAbstractJavaCompiler.java:115) at net.sf.jasperreports.engine.design.JRAbstractCompiler.createEvaluator(JRAbstractCompiler.java:434) at net.sf.jasperreports.engine.design.JRAbstractCompiler.loadEvaluator(JRAbstractCompiler.java:409) at net.sf.jasperreports.engine.JasperCompileManager.getEvaluator(JasperCompileManager.java:382) at net.sf.jasperreports.engine.JasperCompileManager.getEvaluator(JasperCompileManager.java:405) at net.sf.jasperreports.engine.fill.JRFillSubreport.createEvaluator(JRFillSubreport.java:599) at net.sf.jasperreports.engine.fill.JRFillSubreport.loadReportEvaluator(JRFillSubreport.java:582) at net.sf.jasperreports.engine.fill.JRFillSubreport.evaluateSubreport(JRFillSubreport.java:542) at net.sf.jasperreports.engine.fill.JRFillSubreport.evaluate(JRFillSubreport.java:357) at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:383) at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:548) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2600) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:825) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:266) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:110) at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:621) at net.sf.jasperreports.engine.fill.BaseReportFiller.fill(BaseReportFiller.java:414) at net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:120) at net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:103) at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:530) at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:954) at xx.xx.xxxx.xxx.report.processor.JasperReportInternalProcessor.runJasperReport(JasperReportInternalProcessor.java:251) at xx.xx.xxxx.xxx.report.processor.JasperReportInternalProcessor.generateReport(JasperReportInternalProcessor.java:99) at xx.xx.xxxx.xxx.report.processor.util.CommonMDBUtil.onMessage(CommonMDBUtil.java:96) at xx.xx.xxxx.xxx.report.processor.bean.JASPERCommonMDB.onMessage(JASPERCommonMDB.java:28) at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90) at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255) ... 52 more

Firefox is also reporting a false positive for JasperReports-Library_6.21.2.zip. The virus total report confirms it is clean: https://www.virustotal.com/gui/file/9e5e5394dc7f7a609824d7d9e7374184ee41b5609bf23e8b913067acfb57c26d

If you have a large library of reports what you can do is recompile all of them to make sure that you are not using a feature that has been deprecated. This is what I ran into when upgrading 6.5.x to 6.14.x. By doing this I found a few reports that needed to be fixed. To do that easily I created a "TO_COMPILE" folder in my workspace and then put a copy of all the jrxml files there. In Studio you can navigate to the "TO_COMPILE" folder on the project explorer and select Build Project. You can view any issues on the problems tab. If everything checks out you will not need to make modifications to your existing compiled reports.

I got back into editing more reports today and found that the input parameter text field is back to being half-size and unreadable. I cannot continue to make new workspaces when this happens. Has anybody run into this and is there a permanent solution?

I created a new fresh workspace for 6.21.2. After setting it all up again and restarting Jasper my prompt window has been fixed. Maybe the issue had to do with the 6.10.0 workspace not playing well with 6.21.2?

Yesterday I installed Jaspersoft-Studio-CE_6.21.2_windows_x86_64.zip where I was previously using 6.14.0. I noticed when a report has a java.util.ArrayList parameter that the input window is too small and you cannot read the values. Has anybody run into this? How can I get the input box size corrected? Here is the definition of the parameter.

Raphaël is correct about an XML comment line indicating the JSS and JRL used to create the file but you must look at that line using a text editor that is not Jasper Studio. The reason is that Jasper Studio will update that comment as it opens the file skewing the results. I verified this by opening a 6.14.0 file in a 6.20.6 studio and then looked at the source. Comment in text editor <!-- Created with Jaspersoft Studio version 6.14.0.final using JasperReports Library version 6.14.0-2ab0d8625be255bf609c78e1181801213e51db8f --> After opening on 6.20.6 Studio and looking at the source tab <!-- Created with Jaspersoft Studio version 6.20.6.final using JasperReports Library version 6.20.6-5c96b6aa8a39ac1dc6b6bea4b81168e16dd39231 -->

Update 2023-Dec-28, the company decided not to move forward with the homegrown solution and instead use a 3rd party to do the lion's share of the conversion. They were wonderful. The developer who wrote the conversion tool left and we do not have that source since it never became a supported project.

We had this same issue where our sub-report path would change depending on what environment the report was executed for. Our solution was to write a scriptlet that read a configuration file. We would pass the application to it and in return, it would pass back the full path to the location of the report being executed. Here is an example of our development configuration file: # Modify the JASPER_SUBREPORT_PATH to identify where # japer will look for the sub reports # #files on server JASPER_SUBREPORT_PATH=\\\\server\\project\\DEV\\%APP%\\REPORTS\\TEMPLATES\\ Here is an example of our sub-report expression: $P{JasperUtils_SCRIPTLET}.getSubReportPath( "OCR" )+"AAA3-555-001-1295-PDF-SUB01.jasper" The result of that expression using the development configuration previously mentioned would be: \\server\project\DEV\OCR\REPORTS\TEMPLATES\AAA3-555-001-1295-PDF-SUB01.jasper

Yes, variables can be used inside of other variables. Below is an example where I use three different variables in my $V{Campus Header} variable. I believe the issue you are running into is trying to do a direct translation between Crystal and Jasper. You have to work within the reports' defined expression language. You have three built-in options to choose from (java, groovy, and javascript). You can enhance the report engine to add more. You can get more info about that in JasperReports-Ultimate-Guide-3.pdf

100%, the issue is with the $p!{} parameters. I recommend temporarily removing them and putting valid hard-coded values in their place. Once you have a working version add one $p!{} and make sure it works before moving on. Do this for all three parameters. By the end, you should have a working report.

I don't believe there is a way to determine height based on content. When I was making statements/invoices for customers in Asia and Europe I would put the address in multiple bands due to the issue you are running into. To do that I would make sure NOT to use the page header but instead use a group header to display the address. With the address in the group header, you can have multiple bands each one displaying an address part. GH_1a (name) GH_1b (street) GH_1c (city, principal subdivision) GH_1d (country) If the address belongs to the same country that is sending the document then you can suppress that band.