Topic: Mail merge crawls and loses data . . .Why?

[[email protected]]

Hello there . . . can anyone shed some light on this mystery? I posted an earlier version of this question a month or so ago, but now I have been able to troubleshoot the problem a bit more.
We are a small group of teachers and we produce a monthly current events newsletter for Canadian schools (in both English and French). Roughly one third of our customers download a pdf file from our website, and the other 66% want the unit mailed to them.
I recently upgraded from an old G3 blue/white tower (with OS 9) to a G5 tower with OS X Tiger and two gigs of memory. We were also using a couple of old G3 Imacs for basic data processing and email correspondence. We now have a G4 tower as well as a new Emac - and this bug shows up on all three of these computers.
Over the years we have used AW’s mail merge to print envelopes without any problems, but now the 'merging' process just crawls. It wasn't super fast before but it was pretty speedy. Some of the files that we use have over 3,000 entries in the data base and its taking a huge amount of time. Once the file is sent to the printer it prints Ok, but its the initial process that's a real slug.
Also, we have noticed that AW runs up against some kind of memory wall. The envelope template is about 950 k in size. It has three pieces of artwork -- 1) our logo and a return address, 2) a teaser, and 3) a postal permit. Each of these is about 300 k in size. There are also four lines of text that contains the mail merge data.
If we print more than 200 envelopes or so, we start to run into strange and serious problems. The first 200 envelopes are OK but the next 200 or so are missing piece of artwork (the other two are still there.) Then at envelope #400, the envelope is missing two pieces of artwork, and then at envelope #600, all of the three major pieces or artwork disappear. The envelope is completely blank except for the mail merge address info.
This makes no sense at all to me and I am stumped. I have tried everything that I can think of - reinstall AW, repair permissions, print to pdf then to printer, etc. etc. . This exact problems occurs on the other two computers we have in the office. As mentioned, we have used this exact same process for years on ancient G3 computers without any problems. The newer computers have much greater processing power and memory than the old G3’s so I don’t understand why they are so slow and why the data is lost (without any warning?)
Can anyone offer any suggestions? Our business relies heavily on having a fast and accurate mail merge capability.
Thanks in advance for your time.
Eric W in Victoria, B.C. Canada

[Dale]

Hello there . . . can anyone shed some light on this mystery? I posted an earlier version of this question a month or so ago, but now I have been able to troubleshoot the problem a bit more.
We are a small group of teachers and we produce a monthly current events newsletter for Canadian schools (in both English and French). Roughly one third of our customers download a pdf file from our website, and the other 66% want the unit mailed to them.
I recently upgraded from an old G3 blue/white tower (with OS 9) to a G5 tower with OS X Tiger and two gigs of memory. We were also using a couple of old G3 Imacs for basic data processing and email correspondence. We now have a G4 tower as well as a new Emac - and this bug shows up on all three of these computers.
Over the years we have used AW’s mail merge to print envelopes without any problems, but now the 'merging' process just crawls. It wasn't super fast before but it was pretty speedy. Some of the files that we use have over 3,000 entries in the data base and its taking a huge amount of time. Once the file is sent to the printer it prints Ok, but its the initial process that's a real slug.

A common fix for the database slowing down is to delete the AppleWorks User Data folder that's found in your Documents folder on Mac OS X. This is because its AutoSave folder contents have been found to slow down the database.

NB Deleting either the AppleWorks User Data folder or the AutoSave folder won't cause you to lose an data. The reason I suggested to delete the AppleWorks User Data folder (and not just the AutoSave folder) is because it contains other files that can slow down AppleWorks.

Dale

[[email protected]]

thanks for the info Dale.

I have already tried that, and I tried it again, but it doesn't seem to work.

What's very strange is that I get the exact same bug in AW 5 under the Classic environment. For some reason, I start to get problems around the 200th page of merged document. This exact same bug is reproduced on three different machines in our office.

The original document is a Draw document, and I created a regular wordprocessing document - but the result was the same.

I'm thinking that AW hits some kind of a memory wall at around page 200 but it is more of an OS X issue, rather than AW.

I am really stumped.

[[email protected]]

I've been fighting with this again all afternoon. My latest theory is that there is a limit to the size of mail merge file that AW can produce?

Does this make any sense? and if so, is there a way to increase the default memory size?

Thanks again in advance. . . .

[Barry]

I've been fighting with this again all afternoon. My latest theory is that there is a limit to the size of mail merge file that AW can produce?

Does this make any sense? and if so, is there a way to increase the default memory size?

Thanks again in advance. . . .

Cosidering your experience, that seems to be a reasonable hypothesis.

Running under Mac OS 9 and earlier, memory requirements for each application were set in the application's Get Info window. Under OS X, memory allocation is automatic (and dynamic)--memory is assigned to the appication as it is needed.

So unless the merge file is causing AppleWorks to need more memory than is available on your machine, lack of memory shouldn't be the problem.

Apple's specs for AW 6 state the maximum number of Objects in a document is 65 000, which would include each one of those merged graphics, and possibly includes each piece of merged text. Even at 500 pages, that limit wold allow for 130 Objects per page.

65 000 is also the maximum number of pages in a WP document (provided the pages are single column--for multiple columns, divide 65 000 by the number of columns).

Neither of these limits would appear to cause what you're seeing.

Full tech specs for AW 6 are available here:

http://docs.info.apple.com/article.html?artnum=60732

Regards,
Barry

[[email protected]]

Thanks for the Info

I sent my problem files to a Mac expert in France (who contacte me via the Apple sponsored AW forum. He experienced the same problem and this is what he said:

I made some trials.
When I print in a PDF, it ALWAYS quit when "printing" record 318.
I thaught that the record was perhaps corrupted so, I removed it but it quits again on the "new" record 318.
I looked at the quit report and saw that it failed during a Quicktime treatment.
I assume that the problem is not in AW itself but in Quicktime when it is used to render the "logos".
I sent a report to Apple.

He suggested some solutions (like printing the envelopes two times) but none of these solutions will work for us.

I wrote him back and asked:


What seems really strange to me is that the same problem occurs when using AW 5 or 6 in Classic mode, but not in a machine booted in OS9. Is there any way to override the Quicktime in OSX when in Classic mode and use the Quicktime in OS9? Or is there a way to disable Quicktime (if it's not essential) or install an older version of this software?.

I'm sort of at the end of my rope with all of this. If I can't find a good solution, I pretty sure that Word has a mail merge function and I will have to switch everything over if I can't get it to work. As I said before, our businesses really needs a quick and accurate mail merge feature.

[Barry]

Hello there . . . can anyone shed some light on this mystery? I posted an earlier version of this question a month or so ago, but now I have been able to troubleshoot the problem a bit more.
We are a small group of teachers and we produce a monthly current events newsletter for Canadian schools (in both English and French). Roughly one third of our customers download a pdf file from our website, and the other 66% want the unit mailed to them.
I recently upgraded from an old G3 blue/white tower (with OS 9) to a G5 tower with OS X Tiger and two gigs of memory. We were also using a couple of old G3 Imacs for basic data processing and email correspondence. We now have a G4 tower as well as a new Emac - and this bug shows up on all three of these computers.
Over the years we have used AW’s mail merge to print envelopes without any problems, but now the 'merging' process just crawls. It wasn't super fast before but it was pretty speedy. Some of the files that we use have over 3,000 entries in the data base and its taking a huge amount of time. Once the file is sent to the printer it prints Ok, but its the initial process that's a real slug.
Also, we have noticed that AW runs up against some kind of memory wall. The envelope template is about 950 k in size. It has three pieces of artwork -- 1) our logo and a return address, 2) a teaser, and 3) a postal permit. Each of these is about 300 k in size. There are also four lines of text that contains the mail merge data.
If we print more than 200 envelopes or so, we start to run into strange and serious problems. The first 200 envelopes are OK but the next 200 or so are missing piece of artwork (the other two are still there.) Then at envelope #400, the envelope is missing two pieces of artwork, and then at envelope #600, all of the three major pieces or artwork disappear. The envelope is completely blank except for the mail merge address info.
This makes no sense at all to me and I am stumped. I have tried everything that I can think of - reinstall AW, repair permissions, print to pdf then to printer, etc. etc. . This exact problems occurs on the other two computers we have in the office. As mentioned, we have used this exact same process for years on ancient G3 computers without any problems. The newer computers have much greater processing power and memory than the old G3’s so I don’t understand why they are so slow and why the data is lost (without any warning?)
Can anyone offer any suggestions? Our business relies heavily on having a fast and accurate mail merge capability.
Thanks in advance for your time.
Eric W in Victoria, B.C. Canada

Hi Eric,

Are you actually using Mail Merge to merge this information into a Word Processor Document in order to print envelopes? If so, I'd suggest a change in strategy.

Instead of using mail merge, make a new Layout for the database to print the envelopes directly. Place your three pieces of artwork, and any text that stays the same for all the envelopes directly onto the Layout. Add the information you're using Merge for (name and mailing address?) by placing those fields onto the layout.

If your printer accepts envelopes with the same orientation as they're read, you should be able to use a Letter size page for the layout. Just be sure to drag the Body boundary to the bottom of the page to force a Page break after each envelope.

Regards,
Barry

[[email protected]]

Hi Barry

All of this is so frustrating. It all worked so well for us under OS 9 until someone at Apple went and ‘fixed’ it - so it wouldn’t work.

I took a few minutes and tried fooling around with the “layout’ menu using a current database file, but I didn’t really understand what I was trying to do. Would it be at all possible to refer me to a help section or template file, or could you send me a rough file that I could experiment with?

But I also have two questions - if this new method was to work, could we easily convert and use our current database files, and would the size be manageable? The current draw document template is about 1 meg is size, and some of the databases that we use have over 3,000 records - so might this create some sort of monster-sized file?

Thanks again for all of your time.

Eric

[Barry]

Hi Barry

All of this is so frustrating. It all worked so well for us under OS 9 until someone at Apple went and ‘fixed’ it - so it wouldn’t work.

I took a few minutes and tried fooling around with the “layout’ menu using a current database file, but I didn’t really understand what I was trying to do. Would it be at all possible to refer me to a help section or template file, or could you send me a rough file that I could experiment with?

But I also have two questions - if this new method was to work, could we easily convert and use our current database files, and would the size be manageable? The current draw document template is about 1 meg is size, and some of the databases that we use have over 3,000 records - so might this create some sort of monster-sized file?

Thanks again for all of your time.

Eric

The change should add very little to the size of your file, as all you're doing is adding a single layout to the DB. In fact, when I made the necessary changes to the small version of the file you sent, the size of the file actually decreased by about 15 000 bytes! Go figure!?!

That, of course was without adding the three graphics objects you mentioned earlier, so you will see an increase in file size because of those.

Changes:

Switch to Layout mode (Layout > Layout)

Create a new Standard layout (Layout > New Layout... Standard)

Drag the Body boundary to the bottom of the page.

Select all of the field labels and delete them.

Select the last three fields (City, Province and Postal Code) and delete them. (This removes those fields from this layout, where you will not use them. It does NOT remove the fields from the database or from any of the other layouts.)

Create a new calculation field to concatenate the City, Province and Postal Code. Canada Post guidelines state that these three should allbe on the last line of the address, that this line should contain no punctuation, that there should be two spaces separating the two letter province symbol from the items on either side of it, and that line should be all in capitals (except the numbers, of course). The formula below constructs the line to fit those guidelines.

Go Layout > Define fields...
Type CityProvCode in the Field name box.
Use the pull down Type menu to set the field type to Calculation, then click Create.
Enter the formula below in the box.

'City'&" "&'Province'&" "&'Postal Code'

Set "Display result as" to Text, click OK, then click Done.

You'll be returned to the layout, where your new field (and its label) should be already added to the layout.

Select and delete the field label.*

Resize the field frame to match the others, and place the frame so that the left edges of the four fields are aligned, and the spaces between the frames are equal.

Using the Selection tool (arrow), drag a selection rectangle that encloses all four field frames (but not the field label, if it is still on the layout). Drag the fields to the place you want the address to appear on the envelope (you can make adjustemnts to this later).

*If you will be placing a typed return address on the envelope, type that address into the new field label's text frame, format the text as you desie, the drag the frame to it's proper location in the top left corner.

Go Layout > Browse to check the result (making sure you have Page view checked in the Window menu). Print a test sheet on plain paper, and check the positon of the address against a standard envelope. Go back to layout mode to adjust as necessary.

When the address is printing in the correct location, go back to Layout mode and add the graphics elements as you would in the Draw document. Repeat the test print and adjustment as necessary.

Regards,
Barry