General Database Question

Results 1 to 3 of 3

Thread: General Database Question

  1. #1

    Default General Database Question

    I am creating an events calendar written in asp, whereby clients may add new events, meetings and memos etc. All information is stored in an access database. Just recently I decided to restructure my database so that it would be more managable and easier to understand. Now, instead of all events being posted to the &#039;events&#039; table, I have a &#039;meetings&#039; table, a &#039;memos&#039; table a &#039;bookings&#039; table and so forth.<BR><BR>On my actual calendar page, I run a comparison between the actual date on the calendar against the event date. This comparison asks &#039;does the actual date match the event date?...if so write the event title&#039;<BR><BR>My problem is that now, with each event type being held in its own table, I am unsure as to how to query the event dates within one recordset. I am ok with running the sql query. This is no problem, however selecting multiple event types and then displaying their event titles within the calendar is where im lost.<BR><BR>Is it possible to create another table which handles the event date, the event title, and the event id only? Would this make more sense to pool just this information together in one table?<BR><BR>Can access carry values between tables automatically? By this I mean,<BR><BR>table one<BR>field names = autonumber (primary key)<BR> - memo title<BR> - event date<BR> - etc<BR> - etc<BR> - etc<BR><BR>table two - autonumber (primary key)<BR> - memoID (this value matches the primary key of table one as it is populated)<BR> - event date...and so on<BR><BR>Hope this makes sense...Im a little new with access.<BR><BR>Thanks,<BR>John<BR>

  2. #2
    Join Date
    Dec 1969

    Default Put back the EVENTS table...

    ...and have *IT* carrying the event date and time and any other info that is in common between all of the other tables. It also has an autonumber primary key that you use as a FK in the other tables. And, of course, it has a flag that says what *kind* of event each one is.<BR><BR>That&#039;s the only reasonable design, I think.<BR><BR>What you really want is that the main EVENTS table carries enough info to build the skeleton calendar without reference to the other tables. Then ONLY if the user clicks on an event do you go grab the correct supplemental table&#039;s info in the process of showing the full details.<BR><BR>No more autonumbers in any other table, incidentally. No reason for them.

  3. #3

    Default RE: Put back the EVENTS table...

    Thanks Bill...<BR><BR>I understand your point. Guess Ill *put* back the events table...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts