what is it called?

[bobh]

Hi All,

I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

thanks
bobh.

[Salad]

bobh wrote:

Hi All,

I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

It might be called a mistake.

>
senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

How can a primary key have duplicates...unless you set it up that way as
to being a primary key and allowing duplicates? But then it would not
be a primary key...a key that makes that row unique.

>
thanks
bobh.

[bobh]

On Sep 5, 12:04 pm, Salad <[e-mail]:

bobh wrote:

Hi All,

I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

It might be called a mistake.

senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

How can a primary key have duplicates...unless you set it up that way as
to being a primary key and allowing duplicates? But then it would not
be a primary key...a key that makes that row unique.

thanks
bobh.- Hide quoted text -

- Show quoted text -

I agree, it's a mistake or bad design :) but when dealing with, I
guess I would have to call them novice built apps and/or old mainframe
data downloaded to access tables that issue exists. I have run into
many, many situations where the data I have to deal with is far from
perfect or even normalized.
bobh.

[Salad]

bobh wrote:

On Sep 5, 12:04 pm, Salad <[e-mail]:

>>bobh wrote:

>>>Hi All,

>>>I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

It might be called a mistake.

>>>senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

How can a primary key have duplicates...unless you set it up that way as
to being a primary key and allowing duplicates? But then it would not
be a primary key...a key that makes that row unique.

>>>thanks
bobh.- Hide quoted text -

- Show quoted text -

I agree, it's a mistake or bad design :) but when dealing with, I
guess I would have to call them novice built apps and/or old mainframe
data downloaded to access tables that issue exists. I have run into
many, many situations where the data I have to deal with is far from
perfect or even normalized.
bobh.

Well, we don't have the definition yet of yoru problem. Nor does the
word "mistake" provide any method to correct it. I guess you are going
to need to create a field, like an autonumber, to create a true primary
key. Best of luck.

[Larry Linson]

"bobh" <vu******@yahoo.comwrote

I agree, it's a mistake or bad design :) but
when dealing with, I guess I would have to
call them novice built apps and/or old mainframe
data downloaded to access tables that issue exists.

The point is, that a field, or combination of fields, that allows duplicates
is, by definition, not a primary key. Some additional information, or other
information, is needed to distinguish the unique records. You don't have an
"Access problem", you have a "logic problem."

If you can determine what additional or other information is required to
distinguish between the duplicate-indexed records, and then determine which
of the related records belong with which primary record, you will be in a
position to "clean up" or "scrub" your data. Usually, the second of these
is the difficult one, because there will be no indication in the "many-side"
records of that additional information.

If you are lucky, you'll find that those records are identical copies of one
another, and can just delete them. But, usually, that will NOT be the case,
so you, or the data owner (business department affected) will have some
decisions to make.

I have run into many, many situations where
the data I have to deal with is far from
perfect or even normalized.

Yes, that does happen. And, you have to clean it up before you can use it
as relational data.

Larry Linson
Microsoft Access MVP

[rkc]

Salad wrote:

bobh wrote:

>On Sep 5, 12:04 pm, Salad <[e-mail]:

>>bobh wrote:

Hi All,

I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

It might be called a mistake.


senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

How can a primary key have duplicates...unless you set it up that way as
to being a primary key and allowing duplicates? But then it would not
be a primary key...a key that makes that row unique.


thanks
bobh.- Hide quoted text -

- Show quoted text -

I agree, it's a mistake or bad design :) but when dealing with, I
guess I would have to call them novice built apps and/or old mainframe
data downloaded to access tables that issue exists. I have run into
many, many situations where the data I have to deal with is far from
perfect or even normalized.
bobh.

Well, we don't have the definition yet of yoru problem. Nor does the
word "mistake" provide any method to correct it. I guess you are going
to need to create a field, like an autonumber, to create a true primary
key. Best of luck.

Of course an autonumber is not a true primary key and does nothing to
prevent duplicate records so it wouldn't be much help to do that.

[DavidB]

On Sep 8, 7:07 am, rkc <[e-mail]:

Of course an autonumber is not a true primary key and does nothing to
prevent duplicate records so it wouldn't be much help to do that.

Since when?

[rkc]

DavidB wrote:

On Sep 8, 7:07 am, rkc <[e-mail]:

>Of course an autonumber is not a true primary key and does nothing to
prevent duplicate records so it wouldn't be much help to do that.

Since when?

Since always.

[Arch]

On Sat, 08 Sep 2007 07:07:35 -0400, rkc <rk*@rkcny.yabba.dabba.do.com>
wrote:

>
Of course an autonumber is not a true primary key and does nothing to
prevent duplicate records so it wouldn't be much help to do that.

rkc,

Would you be so kind as to explain that? I thought that the intended
purpose of an autonumber was to generate a unique value and that any
attribute that uniquely identified a record could function as a
primary key.

Thanks in advance

[DavidB]

On Sep 10, 11:26 pm, Arch <[e-mail]:

On Sat, 08 Sep 2007 07:07:35 -0400, rkc <[e-mail]>
wrote:

Of course an autonumber is not a true primary key and does nothing to
prevent duplicate records so it wouldn't be much help to do that.

rkc,

Would you be so kind as to explain that? I thought that the intended
purpose of an autonumber was to generate a unique value and that any
attribute that uniquely identified a record could function as a
primary key.

Thanks in advance

It is. The autoumber indeed generates a unique number per record. It
is (all but) the only way to ensure that you have a true unique
identifier for a record and is exactly its purpose. People often fall
for the trap of equating a sequential autonumber field with a record
number though. I always use random autonumbers just to avoid even the
appearance that the field is of any significance other than a unique
record id. Perhaps the other person is saying that it does not
prevent a person from entering any gievn data in the other fields in
your record structure. Thats rather obvious though as a user (unless
constrained by other methods, can enter what he damn well pleases in
any field.

[Jana]

On Sep 5, 8:37 am, bobh <[e-mail]:

Hi All,

I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

thanks
bobh.

Bob:

I beleive the term you are searching for is the "Cartesian Effect".

Jana

[bobh]

On Sep 12, 1:04 pm, Jana <[e-mail]:

On Sep 5, 8:37 am,bobh<[e-mail]:

Hi All,

I can't remember what it is called but I know it did have a name I
thought I remembered it as a 'cascading event' but I don't think
that's what it really is called.

senario:
your primary key has dups so when you create a query which joins the
primary key in the header to the forgien key in the detail you get
bogus results, you get a set of detail of each header record.

thanks
bobh.

Bob:

I beleive the term you are searching for is the "Cartesian Effect".

Jana

Thanks :)