Issues with Script Steps and multiple tables

[madie]

Hi all. I am looking for some help. I recently developed a database for events. The database is used to store temporary information about guests so that reports and name tags can be made quickly while the event is happening. Due to the end users wanting all the events to be completely separate, I have had to create three different tables(invitee table, RSVP table, and a Event table) 11 times so that there can be 11 events happening at the same time. Within each invitee table, for example, is the exact same fields, that are named the exact same way. These field names really can't be changed.

Here's my problem, I need to create a script that would ideally be used exactly the same way across all events. I know that there is a set field script step but this will not let me use but one table at a time (ie. I can't use a calculation to find the appropriate table it is being called from). So I would have to create 11 scripts. I also am aware of the go to object script step but I am, at this moment, the only person in our entire department of 75 who have FileMaker 8.5. Everyone else has FileMaker 8 and I am not sure that I could convince the department to upgrade to 8.5.

Besides setting a tab order on all of the layouts and using the go to next field step to move about, are there any other ways to get around my dilemma?

I appreciate any advice even if it's a "you're SOL". Then I would at least know what I have to do.

Thanks,

Madie

[Søren Dyhr]

11 times so that there can be 11 events happening at the same time.

This seems way to many tables to be honest, take a look at this template - when something gets a tiresom repetitive task to develope, is it a sign of a relatioal flaw usually:

http://www.fmforums.com/forum/attachment.php?attid/7281/

Which is a suggested implentation of:

http://www.filemakerpros.com/CALBASIC.sit

But the point I like to raise here is that an event needs only to be written once the applied ranges make appointments show up in the correct slot ...although there only exists one single related record.

Well this is the hardcore relational approach to the matter, but we should perhaps also address the scripting issue raised ...no there shouldn't be reason to make 11 almost identical scripts even before objectnames arrived could looping a go to next field followed by a comparison between the current field name and the script paramter, control where a "Insert Calculated Result" should drop it's cargo.

--sd

[madie]

I looked at your samples you gave me and I appreciate them but I don't think I made myself entirely clear as to the purpose of the database. It is used to track invitees and guests RSVP responses and their eventual attendance to individual events.

But I will try the script technique you gave me and let you know how well it works.

Thank-you

Jennifer

[comment]

I don't understand why you should need 11 tables for events. There should be one table for Events and one table for Invitations, linked by EventID. (Optionally, if the invitees tend to repeat, you could have a Contacts table.)

RSVP can be noted directly in the Invitations table, and so can be attendance.

[Søren Dyhr]

But I will try the script technique you gave me and let you know how well it works.

You only script-till-you-drop due to an unhealthy relational structure, what I mean is what Comment eloquently put this way:

There should be one table for Events and one table for Invitations, linked by EventID

So I failed my mission by fix'ing you script!

--sd

[madie]

Thanks for your help. I got the script working.

Jennifer