Has Jakarta placed a limit on the length of reports?

HugoFirst
Kilo Sage

I have several reports which contain a (relatively) large number of lines.

Recently, we upgraded to Jakarta Patch 4 and the reports come back with this error:

find_real_file.png

Now a "full report" wojudl have a total number of lines   of about 1,400.   So I am NOT bumping up on the 10,000 limit.

Has anyone else run into this?

1 ACCEPTED SOLUTION

Steve,


Great research and I am sorry the documentation is wrong.   As mentioned in the Export limit properties product documentation the glide.pdf.max_rows system property will allow you to override the default setting of 1000.   This system property might not exist in your instance since the default is set in server side java by the ServiceNow developers but you can create your own system property with a name of glide.pdf.max_rows and type of Integer and set your own custom limit.   I have also confirmed that the server side code also sets a 5000 cap on the number of rows being exported.   So your custom system property can be between 1000 and 5000.



I have submitted feedback on the Product Documentation site stating that the default should be updated to reflect 1000 instead of 5000.   I also suggested noting that the max cannot exceed 5000 as well.


View solution in original post

8 REPLIES 8

Michael Ritchie
ServiceNow Employee
ServiceNow Employee

I am not aware of any changes.   What type of report is this?   Where are you seeing this error message?



I would also suggest navigating to sys_properties.list and search for name contains "limit" to see if you have any set at 1000 that shouldn't be that relate to exporting.


Hello Michael,



Thank you for the quick reply.   The report is a list report of all active records in a simple, custom table, which does NOT extend any other table.


The funny thing is that the report is limited to 1,000 rows when it runs as a scheduled job which sends the report via email.


When I run the report in the UI, I get all the records.   It turns out that there are about 4,000 records.   Still way short of the 10,000 limit.



I also took your advice and checked for sys_properties with a value of "1000" and found a possible clue:


The property is com.snc.apps.publish.maxrows


The comments for this property are:       "Maximum number of records included from each table in an application when the application is published with the Include Data option"



So it's not a slam dunk, but it is a lead.   I'll get back to this thread with an update when I know more.



EDIT: This is a follow up.   I increased the value of com.snc.apps.publish.maxrows to 2,000 and ran the scheduled job to generate the report.


The report is still limited to 1,000 lines.   No improvement was seen.   Sigh...


Steve,


I don't believe that property is it unfortunately.   When you export an application you are prompted if you want to export demo data and that sets the limit on the number of records.



When you say you email the report, does that come via Excel or it is just text within the email?   There are properties to set the max email size which could be affecting it too:


Message body size limit properties



If the list is via Excel or CSV, there are properties you can set for the max rows too:


Export limit properties



If these properties don't exist in your instance you can create them yourself - default values are hard coded via server side Java that get overwritten if the sys_property record exists.   Just make sure you set the Type to Integer.


The scheduled job is sending it as an attached PDF Landscape file.


The body of the email is fairly short.



Interestingly enough, when viewing the doc on export limits, I see a property for PDF files:


find_real_file.png




I checked our instance and it doesn't have that property defined.   The default value in this doc applies to Geneva.


I wonder what the default value is for Jakarta?



EDIT: Update, I checked the docs for Jakarta and the limit listed there is 5,000.   Still, I have to wonder if the value may be different if the property does not exist.   Looks like I'm going to do some experimentation in my dev instance...