Thanks in advance for the help.

Is there a way to save a set of data after a find so that exact list can be pulled up at any given time and cross referenced with another list?

For example. I find a set of entities that are current members and I then mail them a postcard. Next month I want to send all current members another postcard, but I don't want to repeat the ones who recieved it the month prior, so in previous applications (Microsoft Access) I would take the saved table from my first set of data and run an "unmatched" query on the new data based on ID number so that I would then only have a list of those whom did not recieve the postcard, without fear of anyone slipping through the cracks.

Anyone have thoughts?

g

Hi mickey,

I can image a couple ways to do this, depending on whether it's important to remember when each member received his or her postcard. This is just an overview; if you need details, let me know which way you want to go.

If it's is not important to remember the dates things are sent, you could capture all of the IDs of the Members receiving the postcard, and put them into a field in the Mailing table. When you wish to send a new batch out of the same postcard, you'd take the new found set's IDs, remove any that appear in the list of already sent IDs, send to the resulting list of Members, and append their IDs to the list of sent IDs.

If it is important to remember the dates, or any other individual details about postcards that are sent to each Member, then a join table between Member and Mailing will be needed. Let's call it Member-Mailing. In this table will reside the Date Sent field. The idea with this structure is to add a record in the Member-Mailing table for each postcard for each Member, and stick the date in the Date Sent field. When you want to add a postcard to the found set, you would use the relationships to jump to those Members in the found set that do not already have a Member-Mailing record, and then loop through them, creating a Member-Mailing record for each and printing each one out.

The join table approach has the advantage of being able to track when things were sent. This makes it easy to add a mechanism to reprint a set of postcards for a particular date.

Either approach takes some thought to get the scripting all worked out, so expect to spend some time on this.

I don't know why I didn't think of it earlier, but the finding of the Members that haven't yet received the postcard can be simplified a bit by constraining the found set with an omit of those records that have a related Mailing (or Member-Mailing) record.