Thank you for your post.
Does this only occur with this particular database file? That is, if you create a new database file, are you able to print?
What type and model of printer are you using? What printer driver is being used? Keep in mind that printing to a PDF file will use the active printer driver.
I have tried several things to investigate the problem:
Normally I’m not printing anything only using pdf and preview.
1 The problem is only related to one datebase 250MB size. In other databases it is possible to print, print preview, pdf..
2 I have made a recovery file. The process does not report any errors. The recovery file has the same problem.
3 A clone with no records where 1 record is made is able to print
4 A copy of the entire file is not able to print.
5 The printer use the Kyrocera driver which works in all the other databases and programs that I use.
6 Did I do anything new? I import mail content manually copy/paste to the text edit app that removes all unessasary imagefiles that has been in the mail. From there I copy into Filemaker.
7 Other strange things after upgrade to FMProAdvanced 12: FMpro12 doesn’t work properly with Spaces. The old version did. You cannot quickly move the space that contains FMPro12 windows by Ctrl+tab and the select the FM icon. You will not be moved the proper space.
More programs has a problem like it: These programes may create a new file in another space than the first file you open in the particular application: VectorWorks, Sketchup. You have to manually move them together in the same space.
I have investigated more:
Tried to eksport small number of the last 200 records that had been added, to a clone that worked OK with one record.
The database froze again - I thought. Just before I gave up it produced a print preview.
Observing the Activity Monitor it is clear that the program works like a hell. Sadly there is no progressbar telling you anything. The FM12 is soooo slow producing a smal preview. When upgrading some of my presets like: Print only the actually page - is changed. The application tries to produce a preview of a 30.000 record database because the new print dialog is set to: All - as default. This combined with very reduced ability in producing preview looks like a freeze. 2-500 records preview was fast in th old FM. Maby there is something fore you to work with.
Thank you for the detailed information. This does help.
Since your other database files work properly, I can focus on the database file itself. However, I'm still not sure if this is caused by the layout, the file, the fields, etc.
Since the original file doesn't print except with a smaller number of records, is the problem occurring with a particular layout? That is, can you print from other layouts except for the one layout you want to print? Can you tell me more about the particular layout? That is, does it include a Sub-Summary part? How many fields appear in each of the parts? Any special formatting for any of the fields? Typically, how many records print on a page?
If you create a new layout from scratch (do not duplicate nor copy and paste) that includes a subset of the fields, do you have a problem printing?
Continue to keep me posted with any progress.
Note: This is the second recent report of printing problems where "Kyocera" came up. Both posters were Mac users. That may or may not be a coincidence. (The other poster was having trouble with two printers--the other was the infamous bizhup system that has been a source of trouble for mac users for some time now.)
Hi TSGal and Phil
I dug in deep now
My experiment with file size may not be the right approach. Earlier versions of FM have preformed well with the 27000 record big text database, that doesn’t calculate anything except from a field that combine text fields.
FM12 is not freezing while trying to produce a preview of the whole base. Viewing the Activity monitor application built into the Apple System shown the FM12 working and using all the proces space. Trying to abort the FM12 shows in the Force Quit Application - window, that the FM12 application is responcive.
Driver type - recordnumbers
A combined test trying Kyocera and Canon drivers against each other shows a remarkable result:
I made a copy of the 27000 record database in order not to damage the original. I isolated increasing numbers of records from the end of the database, so i would include recently added problematic records.
There is no difference between the Kyocera and the Canon driver. At low numbers of records they produce print preview but it takes exponentiel longer time when record numbers increase.
The ability of creating print preview maybe lost somewhere near 5000 records or takes so long time that any persons patience is lost.
Maybe FM developers should examine this.
I have added the statistics
Here is the file in the right format
Thank you for the detailed information.
There is a flaw in your charting, as the number of records should not be equally spaced since the difference between them are of different values. Additionally, the number of minutes are being graphed at 100 seconds per minute. For example, your values for 1762 records show 3 minutes 33 seconds, where this should be 3.55 minutes, so it would be placed higher in the graph than 3.33. Regardless, your point is made. The number of records printed per second slows down as more records are added. Using your values, here is what I have calculated:
414 = 27.6 records/second
683 = 23.55 records/second
810 = 19.3 records/second
1175 = 14 records/second
1762 = 8.27 records/second
2332 = 7.45 records/second
Again, how many records print per page? Is there a sub-summary? If so, approximately how many sub-summary parts exist? Is the calculation field stored or unstored?
If you could send a clone of the file (a copy with no records), I'll work with it here to determine why the print is crashing and why it is taking so long to print. Check your Inbox at the top of this page for instructions where to send the file.