Need some general guidance

[akrasodomski]

Hi guys, thanks for having me.

I've just started working for a company in London. There is a lot of administration, for which they have a horrible, tangled system of 21387612 excel spreadsheets.
I want to build them an access database, and I was looking for advice as to how you think it ought to be structured. My Access is okay, and with the help of google I usually get by.

We have a database of 3000 members and we run events to which these members are advertised. We also need to store information about the members, and mail merge all of this information.

When there is a new event we have to invite a load of our members to it. Not all of them, mind. We might also need to add new people to invite. We also need to keep track of the number of people we've invited to the event, who has said yes/no etc. etc.

That relationship between new events and old people is one of the main things that is confusing me.

Thanks in advance for the help!

Alex

[winterh]

I have done a new work database over the last 6 months orso, and my best advice would be to think about what you want before you startto make tables forms and queries.

First thing I would do was look at what data each record needs small amount ofinfo things like names and address or do you need every bit of information inthe world, because as i rule your tables should be long and narrow.

The other point to make about table size is if you have one table with everybit of information on it and your database dies the lot has gone, but if youhave a number of tables with data in the chance of you losing the lot is less.


When you build relationship within your table thing aboutthat at the start as I found it was a job to sort later, I would look at thingslike postcodes or maybe a unique client number as this will make the relationshipa lot easier to make and work with.

I have done loads of mail merg within my current database the best way I havefound to do this is have a query which finds the data and link that to the letterand a button on the for to open the doc, but if you need any more help withthat let me know.

Other tip I would do is split the database, as this should make the thing runbetter and more stable, but back the think up before you make any changes.

Hope this helps, if you need any more information let me know.

[akrasodomski]

Hey, thanks very much for the reply. Perhaps I can explain myself in a little more detail.

We run events. I want to be able to create a new event and import various tables of people into the event, from which I can build queries to mail merge and so on.

The thing I am struggling is with the architecture: how could I have a Form which displayed all of these things, and was easily updated from both ends, i.e., if I have a new event I can add old contacts, or if I have a new contact I can add it to a current event.


I also need to be able to keep track of who has been invited and when, but I think that falls under the above problem.





E.g.

Table 1: Contact

Table 2: Event (Has been invited to YES/NO, Is coming YES/NO)

How would I link them so I can record whether a contact has replied YES to a specific event?



Thanks again!