Is this a bug? (2)

[john]

This is a repost, I hope with a better explanation:

1. Create 3 tables, all with 2 fields:
Table 1: Field IDnr (Autonumber,key) and Field Test1 (Alpha50)
Table 2: Field IDnr (Number,key) and Field Test2 (Alpha50)
Table 3: Field IDnr (Number,key) and Field Test3 (Alpha50)

2. In the relation window link on IDnr: table 2 to table 1 (1x1) and table 3
to table 1 (1x1).

3. Create a form via the Wizard and select all fields of those 3 tables to
show up in the form.

4. Run the form and enter "X" into field Test1

5. Tab to field Test2 and again enter "X"

6. Press PageUp and PageDown again

7. Now enter "X" into field Test3

8. Move the cursor to field Test1

9. You will see that the IDnr field of table 3 has gotten the right ID
number.

10. However, the IDnr field of table 2 (which previously got the right ID
number) is
suddenly set to zero. Strangely enough the link with the master record is
still in tact, but it will give 'key and double value' errors later when you
proceed entering other records.

If I skip step 6, this doesn't happen.
How is this possible and more importantly, how can I prevent this nasty
behavior from
happening? Access 2000 and 2002.
Thanks,
john

[Lyle Fairfield]

Possibly, if you posted somewhere, a db containing (just) the tables
and form, more people would examine what you describe and comment. If
you have nowhere to do this, rename the extension to "dat" or something
else innocuous, e-mail it to me (I'm assuming it's small) and I'll post
it for you so that it can be downloaded with a click.

My problems in following up what you say are these:
99.44%of all bugs reported here are not bugs; they are errors by the
poster.
90% of all posters here aren't up front with their subject; they forget
or deliberatly neglect to mention they are doing something else
bizarre, operating in some unusual environment, say jdbc, or they
present an example which is not exactly like the real situation they
want to describe.
It's unlikely that I will ever be involved with the problem you
describe, viz showing three tables linked 1-1 on one form. (I think
that's it).

You may be the exception of course, and you may be raising a valid
point. But it's not worth my time to make the three tables and the form
to find out. But a download? Maybe.

Of course, I've probably wasted as much time now in writing this as I
would have followng up your instructions. Oh well, it's 07:21 here and
not enough coffee yet.

[Lyle Fairfield]

John has sent me this file and it is available for download at

http://www.ffdba.com/downloads/losing id.dat

or

http://www.ffdba.com/downloads/losingid.dat

I hope I haven't screwed it up in the process of copying.

While it's not necessary, one may wish to rename the file extension to
mdb.

[john]

Thanks. I've send the mdb (dat) to you.

It's unlikely that I will ever be involved with the problem you
describe, viz showing three tables linked 1-1 on one form. (I think
that's it).

See my answer to David W. Fenton in "Re: Is this a bug?".

john
"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11*********************@m73g2000cwd.googlegro ups.com...

Possibly, if you posted somewhere, a db containing (just) the tables
and form, more people would examine what you describe and comment. If
you have nowhere to do this, rename the extension to "dat" or something
else innocuous, e-mail it to me (I'm assuming it's small) and I'll post
it for you so that it can be downloaded with a click.

My problems in following up what you say are these:
99.44%of all bugs reported here are not bugs; they are errors by the
poster.
90% of all posters here aren't up front with their subject; they forget
or deliberatly neglect to mention they are doing something else
bizarre, operating in some unusual environment, say jdbc, or they
present an example which is not exactly like the real situation they
want to describe.
It's unlikely that I will ever be involved with the problem you
describe, viz showing three tables linked 1-1 on one form. (I think
that's it).

You may be the exception of course, and you may be raising a valid
point. But it's not worth my time to make the three tables and the form
to find out. But a download? Maybe.

Of course, I've probably wasted as much time now in writing this as I
would have followng up your instructions. Oh well, it's 07:21 here and
not enough coffee yet.

[john]

Download works but Access won't open it because of security issues that may
arise. It says that if I want to open the file I should copy it to my
computer or an available network location. But the file actually is already
on my PC.
john
"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11**********************@h48g2000cwc.googlegr oups.com...

John has sent me this file and it is available for download at

http://www.ffdba.com/downloads/losing id.dat

or

http://www.ffdba.com/downloads/losingid.dat

I hope I haven't screwed it up in the process of copying.

While it's not necessary, one may wish to rename the file extension to
mdb.

[Allen Browne]

John, right-click the file in Windows Explorer (My Computer), and choose
Propereties. You might need to hid the Unblock button.

Without testing this fully, I don't believe this is a bug.
You have 3 tables, with unenforced relations.
You have default values set on the Number fields.

Description
========
Step 1: By entering an X in Test1, you trigger a new record.
At this point Access assigns the autonumber for the new record in Table1.

Step 2: Now you have begun entering a new record for Table2.
This table has a Default Value of zero, in the absence any better
suggestion, Access overrides that and assigns the same number as the
AutoNumber from Table1, so you have a match. So far, so good.

Step 3. The effect of the PageUp and PageDown is to save the record. You now
have one record in Table1, one record in Table2, and nothing in Table3.

Step 4. When you enter a value into Test3, you are starting to add the new
record.
Access assigns the zero default value for the number.
Then it quickly realises that this does not match, and changes it to match
the autonumber from Table1.

But in the mean time, at some point in that process, the zero default value
that was there in Table3 is also assigned to the matching field in Table2.

Analysis
======
There is so much ambiguity about what "ought" to be happening here, that I
don't think I could call this a bug:

a) You have nonsense default values (I know they are defaults) in the
primary keys.

b) You have unenforced relationships, so anything goes.

c) You have a Y-shaped relation, and so the dependencies are circular.

d) Access is trying to be too clever in assigning the key values, and makes
a poor decision based on the poor data structure.

e) You are trying to create records in 3 tables using just one form.

f) You have inner joins as the source of the form, so records will
"disappear" from the form, even when 2 of the 3 appear in the table.

To me, that's not a bug. It is understandable that Access gets confused and
makes poor choices in this case of a nonsense data structure (circular
unenforced relationships with faulty defaults) in a meaningless interface.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"john" <jo**@test.comwrote in message
news:K9********************@casema.nl...

Download works but Access won't open it because of security issues that
may arise. It says that if I want to open the file I should copy it to my
computer or an available network location. But the file actually is
already on my PC.
john

"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11**********************@h48g2000cwc.googlegr oups.com...

>John has sent me this file and it is available for download at

http://www.ffdba.com/downloads/losing id.dat

or

http://www.ffdba.com/downloads/losingid.dat

I hope I haven't screwed it up in the process of copying.

While it's not necessary, one may wish to rename the file extension to
mdb

[john]

Thanks for reviewing it and your help.

I was not aware that numeric fields get default-zero by default. I don't
think that's intuitive, and I guess that's why it didn't even cross my mind
to look there. Anyway, after removing the defaults, it works normally!

b) You have unenforced relationships, so anything goes.

Can you explain what you mean by that?

c) You have a Y-shaped relation, and so the dependencies are circular.

Also with this one: Can you explain what you mean by that?

To me, that's not a bug. It is understandable that Access gets confused
and makes poor choices in this case of a nonsense data structure (circular
unenforced relationships with faulty defaults) in a meaningless interface.

I certainly agree it's not a bug.
What I don't get is why this data structure is so bad (apart from the
zero-defaults).
Do you mean it's strange to have one parent table with two 1x1 child tables?
I'm new to Access and that's probably why I don't see why it is so bad to
have 3 tables in one form.
In fact, in the real app where this error came occured I have one form that
include:
one parent table, three 1x1 childs, and two subforms with both a 1xM child
table.

john

"Allen Browne" <Al*********@SeeSig.Invalidschreef in bericht
news:44***********************@per-qv1-newsreader-01.iinet.net.au...

John, right-click the file in Windows Explorer (My Computer), and choose
Propereties. You might need to hid the Unblock button.

Without testing this fully, I don't believe this is a bug.
You have 3 tables, with unenforced relations.
You have default values set on the Number fields.

Description
========
Step 1: By entering an X in Test1, you trigger a new record.
At this point Access assigns the autonumber for the new record in Table1.

Step 2: Now you have begun entering a new record for Table2.
This table has a Default Value of zero, in the absence any better
suggestion, Access overrides that and assigns the same number as the
AutoNumber from Table1, so you have a match. So far, so good.

Step 3. The effect of the PageUp and PageDown is to save the record. You
now have one record in Table1, one record in Table2, and nothing in
Table3.

Step 4. When you enter a value into Test3, you are starting to add the new
record.
Access assigns the zero default value for the number.
Then it quickly realises that this does not match, and changes it to match
the autonumber from Table1.

But in the mean time, at some point in that process, the zero default
value that was there in Table3 is also assigned to the matching field in
Table2.

Analysis
======
There is so much ambiguity about what "ought" to be happening here, that I
don't think I could call this a bug:

a) You have nonsense default values (I know they are defaults) in the
primary keys.

b) You have unenforced relationships, so anything goes.

c) You have a Y-shaped relation, and so the dependencies are circular.

d) Access is trying to be too clever in assigning the key values, and
makes a poor decision based on the poor data structure.

e) You are trying to create records in 3 tables using just one form.

f) You have inner joins as the source of the form, so records will
"disappear" from the form, even when 2 of the 3 appear in the table.

To me, that's not a bug. It is understandable that Access gets confused
and makes poor choices in this case of a nonsense data structure (circular
unenforced relationships with faulty defaults) in a meaningless interface.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"john" <jo**@test.comwrote in message
news:K9********************@casema.nl...

>Download works but Access won't open it because of security issues that
may arise. It says that if I want to open the file I should copy it to my
computer or an available network location. But the file actually is
already on my PC.
john

"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11**********************@h48g2000cwc.googleg roups.com...

>>John has sent me this file and it is available for download at

http://www.ffdba.com/downloads/losing id.dat

or

http://www.ffdba.com/downloads/losingid.dat

I hope I haven't screwed it up in the process of copying.

While it's not necessary, one may wish to rename the file extension to
mdb

[john]

Thanks again Lyle, for making this available!
john

"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11**********************@h48g2000cwc.googlegr oups.com...

John has sent me this file and it is available for download at

http://www.ffdba.com/downloads/losing id.dat

or

http://www.ffdba.com/downloads/losingid.dat

I hope I haven't screwed it up in the process of copying.

While it's not necessary, one may wish to rename the file extension to
mdb.

[Allen Browne]

The zero-default has always been there, and has always been a pain. It is
gone for the first time in the Access 2007 beta. We're pretty pleased about
that!

Re (b)
In the relationships window, double-click the line joining the tables. The
"Enforce Referential Integrity" box is not checked. Access will therefore
permit bad data in the tables (i.e. the foreign key can contain values that
do not match anything in the primary key of the primary table.)

Re (c)
You have defined relations from:
Table1 =Table2
Table1 =Table3.
but the RecordSource of your form has relations:
Table1 =Table2
Table2 =Table3
so even if you did enforce the 2 relations when you created them, there
would still be no enforced relation between Table2 and Table3.

In general, one-to-one relations are unusual. They are sometimes (correctly)
used for subclassing. They are often used (wrongly) because someone can't
stuff enough fields into one table, and are seeking to get around the
255-column limit. Personally, I can think of one 1-to-1 relation I've
created in the last 12 months, out of literally thousands of relations I've
created in developement and sample databases.

In most cases, a form will feed one table mainly. It might have a lookup
table or two in its RecordSource, but it won't seek to add new records to
those tables as well. If you open Northwind, you will see that's how most of
the forms ar designed. The Orders form gets its records from Orders Qry
(based on Customers + Orders), but it only adds records to Orders. The
Orders Subform is based on a query that gets records from Order Details +
Products, but only adds records to Order Details.

It is too confusing for the user when records disappear from the form
because they are not found in all 3 tables (as in your case), or where
records are duplicated in the form (as happens in a one to many relation
where there are many related records.) So you normally want a main form
(bound to the primary table) and a subform (bound to the related table),
with combos to handle the lookups.

If it's any help, there's a free utilitiy here:
Database Issue Checker Utility
at:
http://www.allenbrowne.com/AppIssueChecker.html
You can download it and have it check your database for a range of issues,
including unenforced relations, foreign keys that allow nulls, text fields
that allow zero-length strings, tables that have no primary key, field/table
names that are reserved words or names that may be ambiguous, and so on.

All the best for your Access work.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"john" <jo**@test.comwrote in message
news:QK********************@casema.nl...

>
Thanks for reviewing it and your help.

I was not aware that numeric fields get default-zero by default. I don't
think that's intuitive, and I guess that's why it didn't even cross my
mind to look there. Anyway, after removing the defaults, it works
normally!

>b) You have unenforced relationships, so anything goes.

Can you explain what you mean by that?

>c) You have a Y-shaped relation, and so the dependencies are circular.

Also with this one: Can you explain what you mean by that?

>To me, that's not a bug. It is understandable that Access gets confused
and makes poor choices in this case of a nonsense data structure
(circular unenforced relationships with faulty defaults) in a meaningless
interface.

I certainly agree it's not a bug.
What I don't get is why this data structure is so bad (apart from the
zero-defaults).
Do you mean it's strange to have one parent table with two 1x1 child
tables?
I'm new to Access and that's probably why I don't see why it is so bad to
have 3 tables in one form.
In fact, in the real app where this error came occured I have one form
that include:
one parent table, three 1x1 childs, and two subforms with both a 1xM child
table.

john

"Allen Browne" <Al*********@SeeSig.Invalidschreef in bericht
news:44***********************@per-qv1-newsreader-01.iinet.net.au...

>John, right-click the file in Windows Explorer (My Computer), and choose
Propereties. You might need to hid the Unblock button.

Without testing this fully, I don't believe this is a bug.
You have 3 tables, with unenforced relations.
You have default values set on the Number fields.

Description
========
Step 1: By entering an X in Test1, you trigger a new record.
At this point Access assigns the autonumber for the new record in Table1.

Step 2: Now you have begun entering a new record for Table2.
This table has a Default Value of zero, in the absence any better
suggestion, Access overrides that and assigns the same number as the
AutoNumber from Table1, so you have a match. So far, so good.

Step 3. The effect of the PageUp and PageDown is to save the record. You
now have one record in Table1, one record in Table2, and nothing in
Table3.

Step 4. When you enter a value into Test3, you are starting to add the
new record.
Access assigns the zero default value for the number.
Then it quickly realises that this does not match, and changes it to
match the autonumber from Table1.

But in the mean time, at some point in that process, the zero default
value that was there in Table3 is also assigned to the matching field in
Table2.

Analysis
======
There is so much ambiguity about what "ought" to be happening here, that
I don't think I could call this a bug:

a) You have nonsense default values (I know they are defaults) in the
primary keys.

b) You have unenforced relationships, so anything goes.

c) You have a Y-shaped relation, and so the dependencies are circular.

d) Access is trying to be too clever in assigning the key values, and
makes a poor decision based on the poor data structure.

e) You are trying to create records in 3 tables using just one form.

f) You have inner joins as the source of the form, so records will
"disappear" from the form, even when 2 of the 3 appear in the table.

To me, that's not a bug. It is understandable that Access gets confused
and makes poor choices in this case of a nonsense data structure
(circular unenforced relationships with faulty defaults) in a meaningless
interface.

"john" <jo**@test.comwrote in message
news:K9********************@casema.nl...

>>Download works but Access won't open it because of security issues that
may arise. It says that if I want to open the file I should copy it to
my computer or an available network location. But the file actually is
already on my PC.
john

"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11**********************@h48g2000cwc.google groups.com...
John has sent me this file and it is available for download at

http://www.ffdba.com/downloads/losing id.dat

or

http://www.ffdba.com/downloads/losingid.dat

I hope I haven't screwed it up in the process of copying.

While it's not necessary, one may wish to rename the file extension to
mdb

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:44***********************@per-qv1-newsreader-01.iinet.net.au:

In most cases, a form will feed one table mainly. It might have a
lookup table or two in its RecordSource, but it won't seek to add
new records to those tables as well. If you open Northwind, you
will see that's how most of the forms ar designed. The Orders form
gets its records from Orders Qry (based on Customers + Orders),
but it only adds records to Orders. The Orders Subform is based on
a query that gets records from Order Details + Products, but only
adds records to Order Details.

I think a form is OK for *two* 1:1 tables. I have an app that's been
in production use since 1999 that puts all the demographic data
about people in the side table, but it's not populated until the
main table's record is marked CLOSED.

It work just fine to have two tables in a form like this. It's the 3
tables that actually cause the problem, seems to me.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[john]

Thanks Allen, for taking time to explain.
See inline.

In the relationships window, double-click the line joining the tables. The
"Enforce Referential Integrity" box is not checked. Access will therefore
permit bad data in the tables (i.e. the foreign key can contain values
that do not match anything in the primary key of the primary table.)

In the former platform I developed in, Paradox, RI was better not used.
Didn't know Access' RI actually does work.

so even if you did enforce the 2 relations when you created them, there
would still be no enforced relation between Table2 and Table3.

This is probly about the distinct row. I put that in as a test and forgot to
take it out.

In general, one-to-one relations are unusual. They are sometimes
(correctly) used for subclassing. They are often used (wrongly) because
someone can't stuff enough fields into one table, and are seeking to get
around the 255-column limit. Personally, I can think of one 1-to-1
relation I've created in the last 12 months, out of literally thousands of
relations I've created in developement and sample databases.

I'm really surprised to hear this. I've always eliminated columns that were
not dependent on the key. I was taught like that. I find it hard to believe
that a 100 field table could be well normalised.

john

"Allen Browne" <Al*********@SeeSig.Invalidschreef in bericht
news:44***********************@per-qv1-newsreader-01.iinet.net.au...

The zero-default has always been there, and has always been a pain. It is
gone for the first time in the Access 2007 beta. We're pretty pleased
about that!

Re (b)
In the relationships window, double-click the line joining the tables. The
"Enforce Referential Integrity" box is not checked. Access will therefore
permit bad data in the tables (i.e. the foreign key can contain values
that do not match anything in the primary key of the primary table.)

Re (c)
You have defined relations from:
Table1 =Table2
Table1 =Table3.
but the RecordSource of your form has relations:
Table1 =Table2
Table2 =Table3
so even if you did enforce the 2 relations when you created them, there
would still be no enforced relation between Table2 and Table3.

In general, one-to-one relations are unusual. They are sometimes
(correctly) used for subclassing. They are often used (wrongly) because
someone can't stuff enough fields into one table, and are seeking to get
around the 255-column limit. Personally, I can think of one 1-to-1
relation I've created in the last 12 months, out of literally thousands of
relations I've created in developement and sample databases.

In most cases, a form will feed one table mainly. It might have a lookup
table or two in its RecordSource, but it won't seek to add new records to
those tables as well. If you open Northwind, you will see that's how most
of the forms ar designed. The Orders form gets its records from Orders Qry
(based on Customers + Orders), but it only adds records to Orders. The
Orders Subform is based on a query that gets records from Order Details +
Products, but only adds records to Order Details.

It is too confusing for the user when records disappear from the form
because they are not found in all 3 tables (as in your case), or where
records are duplicated in the form (as happens in a one to many relation
where there are many related records.) So you normally want a main form
(bound to the primary table) and a subform (bound to the related table),
with combos to handle the lookups.

If it's any help, there's a free utilitiy here:
Database Issue Checker Utility
at:
http://www.allenbrowne.com/AppIssueChecker.html
You can download it and have it check your database for a range of issues,
including unenforced relations, foreign keys that allow nulls, text fields
that allow zero-length strings, tables that have no primary key,
field/table names that are reserved words or names that may be ambiguous,
and so on.

All the best for your Access work.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"john" <jo**@test.comwrote in message
news:QK********************@casema.nl...

>>
Thanks for reviewing it and your help.

I was not aware that numeric fields get default-zero by default. I don't
think that's intuitive, and I guess that's why it didn't even cross my
mind to look there. Anyway, after removing the defaults, it works
normally!

>>b) You have unenforced relationships, so anything goes.

Can you explain what you mean by that?

>>c) You have a Y-shaped relation, and so the dependencies are circular.

Also with this one: Can you explain what you mean by that?

>>To me, that's not a bug. It is understandable that Access gets confused
and makes poor choices in this case of a nonsense data structure
(circular unenforced relationships with faulty defaults) in a
meaningless interface.

I certainly agree it's not a bug.
What I don't get is why this data structure is so bad (apart from the
zero-defaults).
Do you mean it's strange to have one parent table with two 1x1 child
tables?
I'm new to Access and that's probably why I don't see why it is so bad to
have 3 tables in one form.
In fact, in the real app where this error came occured I have one form
that include:
one parent table, three 1x1 childs, and two subforms with both a 1xM
child table.

john

"Allen Browne" <Al*********@SeeSig.Invalidschreef in bericht
news:44***********************@per-qv1-newsreader-01.iinet.net.au...

>>John, right-click the file in Windows Explorer (My Computer), and choose
Propereties. You might need to hid the Unblock button.

Without testing this fully, I don't believe this is a bug.
You have 3 tables, with unenforced relations.
You have default values set on the Number fields.

Description
========
Step 1: By entering an X in Test1, you trigger a new record.
At this point Access assigns the autonumber for the new record in
Table1.

Step 2: Now you have begun entering a new record for Table2.
This table has a Default Value of zero, in the absence any better
suggestion, Access overrides that and assigns the same number as the
AutoNumber from Table1, so you have a match. So far, so good.

Step 3. The effect of the PageUp and PageDown is to save the record. You
now have one record in Table1, one record in Table2, and nothing in
Table3.

Step 4. When you enter a value into Test3, you are starting to add the
new record.
Access assigns the zero default value for the number.
Then it quickly realises that this does not match, and changes it to
match the autonumber from Table1.

But in the mean time, at some point in that process, the zero default
value that was there in Table3 is also assigned to the matching field in
Table2.

Analysis
======
There is so much ambiguity about what "ought" to be happening here, that
I don't think I could call this a bug:

a) You have nonsense default values (I know they are defaults) in the
primary keys.

b) You have unenforced relationships, so anything goes.

c) You have a Y-shaped relation, and so the dependencies are circular.

d) Access is trying to be too clever in assigning the key values, and
makes a poor decision based on the poor data structure.

e) You are trying to create records in 3 tables using just one form.

f) You have inner joins as the source of the form, so records will
"disappear" from the form, even when 2 of the 3 appear in the table.

To me, that's not a bug. It is understandable that Access gets confused
and makes poor choices in this case of a nonsense data structure
(circular unenforced relationships with faulty defaults) in a
meaningless interface.

"john" <jo**@test.comwrote in message
news:K9********************@casema.nl...
Download works but Access won't open it because of security issues that
may arise. It says that if I want to open the file I should copy it to
my computer or an available network location. But the file actually is
already on my PC.
john

"Lyle Fairfield" <ly***********@aim.comschreef in bericht
news:11**********************@h48g2000cwc.googl egroups.com...
John has sent me this file and it is available for download at
>
http://www.ffdba.com/downloads/losing id.dat
>
or
>
http://www.ffdba.com/downloads/losingid.dat
>
I hope I haven't screwed it up in the process of copying.
>
While it's not necessary, one may wish to rename the file extension to
mdb

[Allen Browne]

Inline responses.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"john" <jo**@test.comwrote in message
news:4f******************************@casema.nl...

Thanks Allen, for taking time to explain.
See inline.

>In the relationships window, double-click the line joining the tables.
The "Enforce Referential Integrity" box is not checked. Access will
therefore permit bad data in the tables (i.e. the foreign key can contain
values that do not match anything in the primary key of the primary
table.)

In the former platform I developed in, Paradox, RI was better not used.
Didn't know Access' RI actually does work.

It works, and works really well. I can remember being awed by it when Access
1 was first released, after having to program it all back in the dBase III
days. So this was one of the first web pages I wrote:
Referential Integrity can't be that easy!
at:
http://allenbrowne.com/xbase-07.html

In Access 2000, Microsoft also introduced Cascade-to-Null but no-one seemed
to be aware of it, so this is one of the more recent pages:
Cascade-to-Null Relations
at:
http://allenbrowne.com/ser-64.html

>so even if you did enforce the 2 relations when you created them, there
would still be no enforced relation between Table2 and Table3.

This is probly about the distinct row. I put that in as a test and forgot
to take it out.

Not sure I followed that one. One-to-one relations are directional, i.e. one
of the tables is the primary table, and the enforced relation means that a
value cannot exist in the related table unless it is in the primary table.
But the reverse is not true; there is no problem with having a record in the
primary table that has no matching record in the child table.

So if Table1 is the primary table in a 1-1 relation with Table2, Table1 may
have records that are not in Table2. If Table1 also has a 1-1 enforced
relation with Table3, Table1 may have records that Table3 does not also. As
a result, the children in Table2 don't have to be the same as the children
in Table3: there is no direct enforced relation between the records in
Table2 and the records in Table3.

>In general, one-to-one relations are unusual. They are sometimes
(correctly) used for subclassing. They are often used (wrongly) because
someone can't stuff enough fields into one table, and are seeking to get
around the 255-column limit. Personally, I can think of one 1-to-1
relation I've created in the last 12 months, out of literally thousands
of relations I've created in developement and sample databases.

I'm really surprised to hear this. I've always eliminated columns that
were not dependent on the key. I was taught like that. I find it hard to
believe that a 100 field table could be well normalised.

You're right: 100-field table is extremely unlikely to be normalized, and so
the most common reason we see people trying to create one-to-one relations
in these newsgroups is not a valid reason.

All the best

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:44***********************@per-qv1-newsreader-01.iinet.net.au:

You're right: 100-field table is extremely unlikely to be
normalized, and so the most common reason we see people trying to
create one-to-one relations in these newsgroups is not a valid
reason.

A 100-field table is most likely normalized by breaking it down into
multiple tables where some of the columns in the original table
become rows in the new table.

That is *very* different from breaking a table up into 1:1 related
tables, which does nothing at all to eliminate tables. All it does
is eliminate Nulls, which I don't consider to be part of
normalization. Yes, many null fields can be a sign of
denormalization, but any Nulls that are there because of
denormalization are *not* going to be resolved as a normalization by
moving them to a 1:1 table.

As you said, 1:1 is for subclassing. I can't think of any other use
of it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[john]

I've read the definition of subclassing but I don't understand how this
relates to creating an appropriate 1:1 table. Could you give a table
example?
Thanks
John

"David W. Fenton" <XX*******@dfenton.com.invalidschreef in bericht
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:44***********************@per-qv1-newsreader-01.iinet.net.au:

>You're right: 100-field table is extremely unlikely to be
normalized, and so the most common reason we see people trying to
create one-to-one relations in these newsgroups is not a valid
reason.

A 100-field table is most likely normalized by breaking it down into
multiple tables where some of the columns in the original table
become rows in the new table.

That is *very* different from breaking a table up into 1:1 related
tables, which does nothing at all to eliminate tables. All it does
is eliminate Nulls, which I don't consider to be part of
normalization. Yes, many null fields can be a sign of
denormalization, but any Nulls that are there because of
denormalization are *not* going to be resolved as a normalization by
moving them to a 1:1 table.

As you said, 1:1 is for subclassing. I can't think of any other use
of it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"john" <jo**@test.comwrote in
news:pc********************@casema.nl:

I've read the definition of subclassing but I don't understand how
this relates to creating an appropriate 1:1 table. Could you give
a table example?

In an application for a client I did, there were three different
types of contact records, but the three different types needed
completely different fields. So, the field shared by all three
contact types when in a main contact table, and the fields that were
specific to the specific subclasses of contacts when in three
separate tables in a 1:1 relationship.

Two subcclasses can be represented with just one side table, as in a
case I described earlier where a case had no record in the 1:1 side
table until it was closed, when demographic data got recorded in the
other table. Thus, there were two subclasses, open and closed, with
open represented by the main table, and closed represented by the
main table+the demographics table.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[john]

Thanks. I get it...
john

"David W. Fenton" <XX*******@dfenton.com.invalidschreef in bericht
news:Xn**********************************@127.0.0. 1...

"john" <jo**@test.comwrote in
news:pc********************@casema.nl:

>I've read the definition of subclassing but I don't understand how
this relates to creating an appropriate 1:1 table. Could you give
a table example?

In an application for a client I did, there were three different
types of contact records, but the three different types needed
completely different fields. So, the field shared by all three
contact types when in a main contact table, and the fields that were
specific to the specific subclasses of contacts when in three
separate tables in a 1:1 relationship.

Two subcclasses can be represented with just one side table, as in a
case I described earlier where a case had no record in the 1:1 side
table until it was closed, when demographic data got recorded in the
other table. Thus, there were two subclasses, open and closed, with
open represented by the main table, and closed represented by the
main table+the demographics table.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/