Re: Many to Many Relationship

Okay- I can start from scratch.

I have two lists. Let's call them List A and List B. List A and List B each
has two columns, named InvoiceNumber, Invoice Date. All I want to know is
what data appears on both lists, what data appears on list A but not on list
B, and what data appears on list B but not on list A. Should I ust Excel or
can Access easily give me the information I'm looking for?


"Steve Schapel" wrote:

> Crystal,
>
> I enjoyed the story of the circles. This conveys your meaning well. In
> fact, it conveys it much better than your table-based explanation. This
> is because your table design does not adequately reflect the nature of
> the information you are trying to manage... if you don't mind me saying
> so. I would really suggest taking a deep breath here, and start again.
> There is no way this can be interpreted within the concept of a
> many-to-many relationship... it just doesn't fit that model. And the
> idea of using different tables to store different information about the
> invoices is really asking for trouble. You have Invoices. Whether any
> given invoice was received in the office via the store or through the
> mail from vendors, this is information *about* the invoice, and as such
> needs a *field* in the Invoices table to describe it. Similarly,
> whether any given invoice from the store has or hasn't been processed
> through the office, this is information *about* the invoice, and as such
> needs a *field* in the Invoices table to describe it. If you try to
> descibe this information according to which table it's in, by having
> different tables for different characteristics of the same data, this is
> called the "tables as data" trap. I still don't really know enough
> about you business procedures to get too specific. But I would say all
> the information about the invoices goes in one table. And imagine you
> would have one field which might be called ReceivedBy where the data
> will be entered either Store or Office, and another field called
> DateProcessed so if this field is empty you will know that the Office
> has not processed it yet. Etc. And then any queries to retrieve the
> kinds of data summaries that your initial question was about, will be
> very simple.
>
> --
> Steve Schapel, Microsoft Access MVP
>
>
> Crystal K wrote:
> > Hi Steve,
> >
> > Thanks for attempting to understand the scenario. Let me try again. There is
> > only one store and one main office. The store gets invoices and later
> > forwards them to the main office to process. The main office process invoices
> > received from the store or through the mail from vendors directly. So I want
> > to know the three things from my earlier post.
> >
> > I wish I can draw circles. One circle would contain data on the invoices the
> > store received. A second circle contain data on the invoices the main office
> > processed. When you push the two circles slightly together (the store circle
> > on the left and the main office circle on the right), the middle will
> > intersect. The middle intersecting part are the invoices that the store
> > forwarded to the main office to process. The left non-intersecting part are
> > the invoices that the store forwarded to the main office that didn't get
> > processed. The right non-intersecting part are the invoices that the main
> > office processed received through the mail (not forwarded by the store).
> >
> > I want to know the invoices the two tables have in common and those that are
> > not common to each other. I hope the scenario is a little clearer....
>
.

Relevant Pages

  • Re: Many to Many Relationship
    ... And the idea of using different tables to store different information about the invoices is really asking for trouble. ... Whether any given invoice was received in the office via the store or through the mail from vendors, this is information *about* the invoice, and as such needs a *field* in the Invoices table to describe it. ... And imagine you would have one field which might be called ReceivedBy where the data will be entered either Store or Office, and another field called DateProcessed so if this field is empty you will know that the Office has not processed it yet. ... A second circle contain data on the invoices the main office processed. ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Many to Many Relationship
    ... Thanks for attempting to understand the scenario. ... only one store and one main office. ... The store gets invoices and later ... >> Table Name: MainOffice ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Simple DBMS in VB
    ... Because you want to store variable length data, ... but complicates updating when changes in the data necessitate ... seem the Genre table and the Album's song lists would not need updating ... is to keep the images in their ...
    (microsoft.public.vb.general.discussion)
  • Re: Simple DBMS in VB
    ... Because you want to store variable length data, ... but complicates updating when changes in the data necessitate ... seem the Genre table and the Album's song lists would not need updating ... is to keep the images in their ...
    (microsoft.public.vb.general.discussion)
  • Re: Advice on storage and retrieval
    ... If you want to store a 2, for example, you wrap it up in an object, if you want to store ... most efficient storage method for the data type, because everything is held in an object. ... Also, if you have items that have multiple unique members, you need a custom storage ... lists of different items.... ...
    (microsoft.public.vb.general.discussion)