[AccessD] Many to Many relationship issue

Maybe I used flatter incorrectly,  and maybe you use dependencies in a
different context than I do.

But I guarantee, GUARANTEE you that to keep an accurate audit and history
of all the dependencies needed to populate what happened, when, on which
jobs, for which companies, involving whom and in what roles... and be able
to trace those deta I ls from the call table back to their components in
the entity tables YOU COULD NOT DO IT while at the same time creating
future transactions with fresh, current details. A call table is a history
table, not an active environment. The active environment changes, the
history/audit/warehousing details likely will NOT.

Trying to preserve relationships kills, kills, kills reporting veracity

If you want to improve "the quality" of the thread, get to it (but I don't
like your implication that what has been offered so far is of low quality,
that's rather rude).

I am answering from my experience, yours is a welcome voice.

I do not have any relationship diagrams to offer you.
On Apr 12, 2014 12:38 PM, "Arthur Fuller" <fuller.artful at gmail.com> wrote:

> Bill, et. al. on this thread,
>
> I seriously take issue with your comment that "the flatter your information
> is, the less outside dependencies..."
>
> In my opinion, this is wrong, wrong, wrong. Or to phrase it another way,
> this is the reason for Views, as opposed to direct table Selects.
>
> But this whole thread makes me wonder, Is there a way that we can create a
> relational diagram, whether in Access or SSMS or some similar tool, and
> include the diagram in the original post or its replies? For this sort of
> discussion, a picture is worth 1000 words.
>
> Can this be done? I've not yet tried to do this; hence the question. But I
> think that if it can be done, this would go a long way to improving the
> quality of the threads.
>
> Arthur
>
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>