Your questions seem to indicate that you're on the right track here. You do need a third table; They'd be related like this:
The key fields would match up like this:
Contacts::ContactID = Contact_Event::ContactID
Events::EventID = Contact_Event::EventID
You can place a portal to Contact_Event on your contacts layout and include fields from Events in the portal to show event details. This portal will list all events for the current contact.
You can place a portal to Contact_Event on your Events layout and include fields from contacts to show names and other details. This portal will list all contacts invited to that event.
You can place one or more additional fields in Contact_Event to show the contact's status (invited, Rsvp, attended, etc.)
worked a treat - and once I'd figured out that you have to commit after settting a field, the export script worked as well.
Glad it worked, but I don't quite follow why you need an export script for this. The two portals should be able to do all the work during basic data entry and then you can simply run a report based on the join table to list all the contacts for a given event. or all the events for a given contact.
i had a similar problem to event registration... how can i import 300 contacts in portal to the specific events only.