I have a couple of printing forms structured as master-detail.
For a customer of ours, in production with Servoy 3.1.8, the db growth considerably and some printout could have few thousands of records in the detail part (actually around 1500 but they will be more in the future).
I just found that 32 pages is the maximum number of pages generated in all these forms regardless of the real number of record to print to be printed.
Where is this limit defined?
Is it a structural limit in Servoy or I should tune some parameter to manage this?
Where can I find more informations on printing limitations?
Thinking about this problem I was wondering how Servoy could manage very large dataset to be printed or complex printing…
Let’s assume 20.000 record to be printed…
Let’s think about line or page break connected to specific conditions (not related to sorting of the foundset and subsummaries)
???
I had some experience with another development tool that has specific events/methods/properties to overcome this kind of problems:
Some events like beforePrintingRecord or afterPrintingRecord to force as example line breaks and page breaks with methods connected to these events
Special type of form discarding records from memory after a record is printed
…but up to now in Servoy I didn’t find anything like these. Am I missing something?
The issue is still there also in Servoy 3.5.10; the application is correctly selecting 1722 record but printing stops after approximately 1200 record on page 32 or 33 depending from the specific form.
Has anyone found something like this also in Servoy 5x ???
I feel the only solutions I have are:
Segmenting the printout in multiple PDF joining them in a later stage
Moving quickly to Servoy 5 and giving a try to Jasper.
Am I missed any documentation?
Any hint excluding ‘do not print such huge documents’?
There is no such limitation. I just printed 5500 records on 550 pages without problems in latest 5.1 build. (both print preview and actual print to a pdf printer)
But it shouldn’t be a problem in older versions either (only if you stumbled on a bug). Do you see this happening in simple solutions too? If so, please attach a simple solution that can show the problem.
gianni:
Thinking about this problem I was wondering how Servoy could manage very large dataset to be printed or complex printing…
Let’s assume 20.000 record to be printed…
Let’s think about line or page break connected to specific conditions (not related to sorting of the foundset and subsummaries)
You can only set properties like page breaks on form parts and not from scripts currently… If you think it would be helpful, you can create a feature request and explain why it would be nice to have it.
Jasper is also nice - check it out if you have the time.
tnks for your test…and sorry for being late to answer.
The problem is there and probably is related to something in my form causing the behaviour.
The structure of the printing form is:
The form is a record view (locked)
The form is composed by header-body-footer; the header is 50px high and also the footer. The total is 2390px so the body is 2290px long
There are few fields in the header (4) together with 6 labels and 1 label showing an image (company logo)
There are no fields in the footer but there is 1 labels showing an image (software developer)
The body contains around 125 fields, mostly calculated field based on the single record extracted from the db, and 160 labels
At the end of the body there is a tab panel linking the detail form that should print around 1800 record but for whatever reason it is not able to do it properly.
The form could be printed by the user after a preview mode (5%) or to a pdf directly (95%). The end user has reported the problem printing to PDF directly.
The itext.jar we are using is version 1.2.2 (but I am not completely sure about this…)
You can find here attached a PDF showing the problem. In the different test I’ve done (changing the dimension of fields in the detail form) the last record of the detail section is more often truncated in the middle while in the example I have attached is complete.
We are working actually in production with an heapSize of 384MB.
Tell me more about the detail form. Form type/field types, …
It looks like the form or a field (for example if you are using HTML area) isn’t calculating it’s size correctly, especially if you say last record is sometimes truncated.
The detail form is a very simple form type “List (locked)”; it has only the body, no header no footer, 31px high.
On the form there are 22 fields on two rows plus a field at the beginning being two rows high…
The global layout is something you can see it clearly in my attachment.
Some of those fields are in reality empty labels to respect a required user view.
At the end there are 19 fields and 3 labels.
Fields are 15px high and are just touching one each other so there is 1px spare at the end on the body to create a separate view of each record for the end user.
Fields are connected to a style:
field.compatto
{
font: 10pt Arial Narrow;
}
While labels have just a border of 1px on the four sides.
Fields/labels were initially 20px high with body 41px high; trying to solve user issue i reduced them to 18 then 16 then 15px.
Number of record printed increased reducing field size from 1155 to 1216 but the problem remained; in those test I found the last record truncated.
Pages printed were always 32-33.
All fields are extracted directly from db…there isn’t any calculated field.
The detail form is connected to the main one with a relationless tabpanel; the query is code driven with a find()/search() construction.
My PC has plenty of free disk space so it can’t be a printing space issue…
If you are interested in other details pls let me know.
I think this kind of hudge tab panel printing isn’t handled correctly - in most cases ppl. do not want to print with tab-panels. Please add a case to our support system and we’ll see what we can do. http://servoy.com/s
For now, if possible, try using two separate simple prints - one for the first part of your form and move the tab-panel part into a second print.
I’ve opened the case 278806 with a little mistake: referring to Servoy 5.1 instead of Servoy 3.5; I’ve committed the record once and cannot change it now.
By the way you raised a question in my mind:
how could a servoy master-detail printing form with a subset of a relation being implemented without a tabpanel and a customized query?
gianni:
how could a servoy master-detail printing form with a subset of a relation being implemented without a tabpanel and a customized query?
If you want a subset of a relation, you either need a custom query or another more restrictive relation.
What I can think of now:
2 separate form prints with master as one form and details as another form populated by a customized query.
same as first - but print to PDF and merge them.
populate a HTML area with the details instead of using a tab-panel in the master form - you could do this using a calculation. But be careful to avoid a possible hudge performance loss that could be caused by this when not printing - return “” in the calculation when not printing (you can set a global when printing from JS or when entering printPreview and reset it after the script finishes or the form is shown again in normal mode).
gianni:
how could a servoy master-detail printing form with a subset of a relation being implemented without a tabpanel and a customized query?
If you want a subset of a relation, you either need a custom query or another more restrictive relation.
What I can think of now:
2 separate form prints with master as one form and details as another form populated by a customized query.
same as first - but print to PDF and merge them.
populate a HTML area with the details instead of using a tab-panel in the master form - you could do this using a calculation. But be careful to avoid a possible hudge performance loss that could be caused by this when not printing - return “” in the calculation when not printing (you can set a global when printing from JS or when entering printPreview and reset it after the script finishes or the form is shown again in normal mode).
Andrei,
tnks again for your answer and some comments on them:
Solution1: technically this is not a master-detail form but they are two separate printouts. The end-user probably will feel the same but he/she could accept it after some/many complains.
Solution2: technically this is not a master-detail form but they are two separate printouts that seems as a single printout for the end-user (IMHO the best option!)
Solution3: I feel this solution is using a little bit too much central memory because the HTML area must be composed in memory and as soon as the number of records to be printed is increasing (IMHO the worst option or better an unfeasible option for real printing form, just a prototyping quick&dirty technique)
Now my problem is:
Could Servoy identify where the problem is hidden?
Based on solution2 should I rewrite all the basic printing options of my application? Consider there are a total of 64 possible master-detail printouts based on 12 physical forms called with three params generating 64 possible combination; half of these have a detail form at the end. It is A LOT of damned (=unpayed) work reworking and retesting everything in 3 different customer parametrization because of a tech bug…A difficult path to follow!
Pls tell me Servoy will do everything to find the bug I have encountered!
I was trying to dig more into the case I’ve recorded and I’ve just discovered something could be interesting about this problem.
After trying to use my printing functions in interactive mode (generating preview) I’ve found more messages like this in the servoy log file:
2010-03-11 18:21:04,500 ERROR [TaskExecuter[0]] com.servoy.j2db.util.Debug - No break found
I haven’t the debug active !!! neither I’ve activated any break point !!!
It seems it is generated only when the printing is truncated.
I feel the number of messages of this type I found in the log is directly related to the number of records missing in the printing.
The behaviour is repeatable.
I didn’t notice it before…
Do you have any idea on why this message could be generated?
It is not related to your problem. That error message appears when Servoy is not able to find a suitable place to put the page-break in your print without splitting one or more form components in two parts. It tries to keep all components on the main form on either one page or the other, or at least it tries not to split text (in case you are using text areas/html areas).
In your case the tab-panel takes up about 30 pages - so it’s split about 30 times. This is the number of error messages that you should see.
The thing is, the Servoy printing sub-system was not designed to print tab-panels nicely. It was only meant for printing 1 form at a time.
I’ll post an alternate way to print what you want soon - I just have to change something to make that work.
This is what you have now: main form (f1) with 1 record and tab-panel (f2) with thousands of records.
This is how you should refactor the print to make it work:
remove tab-panel and header/footer from f1
main form that you will print becomes f2
on f2 add the header/footer parts you removed from f1
on f2 add a “Leading Grand Summary” part, then on it:
add a tab-panel that shows f1; configure the tab-panel as you had it previously on f1 (borders, transparency, …) - but this does not guarantee page breaks will not cut fields in f1 in half (see my previous post) OR
simply add all the fields in f1 (then you no longer need f1, but you would have to populate these fields through JS)
[/:m]- allow “Leading Grand Summary” part to break across page bounds[/:m][/list:u]
What I had to change is make the “Leading Grand Summary” part honor the allowBreakAcrossPageBounds property - as in current builds it could only show on the first page.
So you will be able to use this approach starting with Servoy 5.1.1.
We do not plan on adding support for nice tab-panel printing to Servoy for now - as for more complicated prints you can always use Jasper.
Let me try to recap with other words the issue to understand if I have understood correctly.
The Servoy printing subsystem in Servoy 3.5.x (but also in Servoy 5.x) has at least one undocumented limitation regarding tabpanels usage for printing.
In a printing form with two entities related through a one to many relationship (classic master-detail form) if a tabpanel is used to implement the relation on the many table side, the form could be able to print hundreds, maybe one thousand, records on the many side, no more.
Alternative implementations to be considered to solve the issue are:
If the form is simple (only two tables related in a one to many relationship) the form could be implemented in the reverse way (a detail-master form) using the many entity as the primary entity and implementing the relation through the tabpanel from the many entity to the one entity. With this implementation the tabpanel is used to print a single record and the underlying limitation is not discovered.
With more complex printing forms (many one to many relationship with many records to be printed in the same printing form) there could be no solution at all to this issue using a single printing form within the standard Servoy printing subsystem; an alternative is printing using Jasper through Jasper plugin.
Trying to solve this first issue your further analysis has focused on another limitation related to “Leading Grand Summary” (and probably to “Trailing Grand Summary” also). Up to Servoy 5.1 a “Grand summary” either Leading or Trailing is not able to print on more than one page. This limitation is going to be solved starting from Servoy 5.1.1; a new property allowBreakAcrossPageBounds will be available to enable these “Grand Summaries” to print across multiple pages.
By the way to repair the issue in my application I think I will let the end-user finding the issue in the interactive usage (only 5%) describing it as a limitation of the preview mode; I will solve it in the batch usage (95%) printing two separate PDF and joining them in the single one end-user is used to see.
gianni:
Trying to solve this first issue your further analysis has focused on another limitation related to “Leading Grand Summary” (and probably to “Trailing Grand Summary” also). Up to Servoy 5.1 a “Grand summary” either Leading or Trailing is not able to print on more than one page. This limitation is going to be solved starting from Servoy 5.1.1; a new property allowBreakAcrossPageBounds will be available to enable these “Grand Summaries” to print across multiple pages.
“Trailing Grand Summary” didn’t have the ‘one page only’ problem.
‘allowBreakAcrossPageBounds’ is not new (just it had no effect in the past for “Leading Grand Summary”) - you can see it in Properties view when selecting a part. It corresponds to “Allow part to break across page boundaries” checkbox in form editor’s “Parts” tab.