Sounds like you are trying to use one table where you need more than one table linked in relationships.
A typical system for handling orders looks like this:
Customers----<Invoices----<lineItems>----Products (----< means one to many)
with this setup, a given customer only has one record in Customers with the shipping address, but possibly many records in invoices--one for each order and each invoice can list multiple items for that single order.
In most cases, you would then print one shipping label for each record in Invoices and not have an issue with duplicate labels.
While the table names are slightly different, the Invoices starter solution that comes with Filemaker 11, 12 or 13 is designed on this basic data model.
Thank you for the input and I did think about that, but it may be overkill and very complicated to do.
The list is created on the fly (originally) and this are one time only "event" customers. They are receiving a photograph and because they have multiple groups at the event (each getting a photograph) I'm not sure how the Invoice Starter System would work.
Also, this list of customers [event leaders] will probably never be used again or at best once or twice per year.
If you still think the Invoice Starter is the best solution I will dig into it and take a look.
I wasn't actually suggesting that you use the Invoice Starter, but that you examine it as an example of how this might be set up.
I was also trying to point out that you haven't really describe how you have set up and use your tables.
However you work out the final details the point is to set this up so that you do not have duplicate shipping address data in different records in the first place. Whether you ever use that data again once the event is over is not really part of my reason for making that suggestion.
It is possible to set something up that drops out the duplicates, but it's also rather complicated so I'd rather set up a More complicated design that is a better over all design, than a more complicated design built one what appears to me to be a less than optimum database design.