Table of Contents: A permanent remedy to the problem of reports and forms not fully printing as a result of timing out. A) Prototype 1) print.php 2) hello.php API 3) pap.class_print.php 4) hello_again.php A permanent remedy to the problem of reports and forms not fully printing as a result of timing out. The "Personal Health Survey" is a large PDF document. In some instances, depending on the number of employees, a large number of these PDFs need to be generated which can cause the system to time out. This solution fixed that problem by introducing a mechanism that printed off the total number of PDFs in "chunks." A) Prototype (back to top...) 1) print.php page (back to top...) Here's the way this works: You click on a button that opens up a popup window that has an animated "gear" icon displayed that gives the user the assurance that something is being processed. Below that icon is a "counter" that displays the number of "laps" that are being accomplished. What the user doesn't know is that each "lap" is a bundle of 10 rows. That number of "laps" is the number of times the code will retrieve 10 rows before the entire dataset has been processed. In between each lap, the connection to the database is severed while simultaneously routing the process back to the beginning with the ID of the last row that was processed in tow so the cycle knows where to start when the next "lap" is begun. Here's the code I used to make a prototype that includes some "markers" (❶ , ❷ , ❸ ) to better explain the logic behind the code. First, here's the "print.php" page. This is where the button that initates the process resides... ❶ the number of records to be processed was displayed in the UI. We're just grabbing that number and dividing by 10 and adding 1 so our first round of processing, which subtracts "1" from the total by default, doesn't stop short of processing the whole dataset by 10 records. ❷ the class that is typically "hidden" which contains the "gear" graphic / popup that affords the user the opportunity to "see" that things are being processed ❸ the initial query that's retrieving our dataset in groups of 10. ❹ the "data" that's being displayed is the number of laps that are being done as things are being processed. 2) hello.php API (back to top...) So, you click a button that has the "print_forms" class attached to it and you get a little popup graphic that is also triggering the functionality represented in the "hello.php" page. "hello.php" is the API that's doing all of the heavy lifting. ❶ "pap.class_print.php" is the code that has the "init_genPSM" method which is what's being called by "$bob." ❷ here's where you're subtracting "1" from the number of laps the process is stated to complete ❸ meet, "$bob." $bob is going to trigger the functionality that's generating the PDFs, store them in a directory and the provide the needed ID of the last row that was processed so the system knows where to start in the context of the next "lap." ❹ the actual method located on "pap.class_print.php." It's going to generate 10 PDFs and then return the ID of the last row that was processed. ❺ $laps is the value that originally came from the value in the "print_forms" function. Once this process is initiated though, the "hello_again.php" page will decrease that value by 1. ❻ at this point, $bob has fired and it's going to send the id of the last row processed to "hello_again.php." The sole purpose of that page is to simply take an inventory of the number of rows / laps that have yet to be completed, update the text in the "gear" graphic and route the whole process back to "hello.php." ❼ here's the value of $bob" embedded within the URL that's routing the process to "hello_again.php." ❽ when there are no more laps, you then send the appropriate text alerting the user the process has completed and you include the link to the zip file. As long as there are laps, you'll display the text that's coming from the "hello_again.php" file which communicates the number of laps that been completed. ❾ the text that will be displayed on your popup window when the process has completed ❿ the close button for the popup window 3) pap.class_print.php (back to top...) This is the "pap.class_print.php" page. This is where all of the heavy lifting is happening, as far as the query that grabs the IDs that need to be processed, then generates the PDFs and finally returns the PrimeID of the last row that was processed. It's here, too, that the connection to the database will be severed in order to prevent the process from timing out. ❶ this is the method that was triggered a monent ago on the "hello.php" page (see ❸ ). This is going to collect the 10 PrimeIDs that need to be funneled into the method that will created the PDFs. And this will only gather 10 of those PrimeIDs that have a value that is greater than the last PrimeID that was processed in the last "lap." ❷ the actual SELECT that gathers the correct PrimeIDs based on the incoming arguments ❸ the count / reps value is keeping track of how many PDFs have been successfully generated ❹ the $pdfPath is the directory where all of the PDFs that are being manufactured are being stored ❺ this is the method that's actually assembling and creating the actual PDF ❻ the URL / Zip File that the user will be able to access that contains all of the PDFs ❼ kill the database connection so it doesn't time out ❽ return the last PrimeID value 4) hello_again.php (back to top...) ...and finally, here's the "hello_again.php" page. This is the text as well as the piece of the code that's "bouncing" the process back to the "hello.php page. The text will change and display the link to the zip file when the process arrives at the last lap: ❶ here's where the process is routed back to the "hello.php" API