In a message dated 2009.04.09 13:32 -0500, Drew Jensen wrote:
That depends on the database you use. As Base itself doesn't care,
the database has the responsibility to do the right.
But that's my question: Base does not seem to care about direction -
but that is the front end to the database. So how does the back end
know what we want?
... But in the relation ships design you can select what should
happen on each side differently. So in your example just define that
when an employee is deleted than his photo should be deleted as well
and when only his photo is deleted the employee stays untouched.
...
At the top of the dialog are two drop down lists under "Tables Involved"
The table in the left drop down is the "referencing table" and the table
in the right drop down is the "referenced table"
Ah - *that* is what I was missing. I thought it had to be simple, but just
could not find that simple thing in the Help or other documentation.
Thanks! I'm sure Ocke knew that, too, but probably figured it was something
everyone knows. He did not reckon on my aptitude for obtuseness.
... Update and Delete settings are always applied per the SQL standard.
In my words - not the standards - Cascade [Update] and Delete settings
come into play ONLY when the record being "referred to" is updated or
deleted.
Yes, that I understood - and it probably would have served my question
better to say "referring" or "referred to" rather than "cascade".
However, from this point on I have studied your answer very carefully, and
I'm afraid your point may be lost on me:
... Now then however, you toss in another wrinkle here..when you mention a
1..1 relationship between Employee and EmployeePhoto.
Truth is you can't create a 1..1 relationship with Base.
What you can create is a 1..(0 or 1) relationship and that is fairly easy.
?? - I can't, but I can? (Also, is a "1..0 relationship" anything more than
the trivial case of, say, an Employee without an EmployeePhoto?)
Let's say I have an Employee table with a field EmployeeID (integer,
auto_generated) as the Primary Key.
[1] I create a EmployeePhoto table with EmployeePhotoID (integer,
auto_generated) as the Primary Key and a EmployeeID (integer) for the
Foreign Key field. Now if I create a relation in the relationship window
notice that the line connecting the two tables has a 1 next to Employee
[at the EmployeeID field] and a n next to EmployeePhoto [at the
EmployeeID field].
[2] However if I instead create my EmployeePhoto table as EmployeeID
(integer) Primary Key [not this is not auto_generated] ... Now when I
use the relationship window to create that relation there is a 1 next to
Employee and a 1 next to EmployeePhoto. The EmployeePhoto.EmployeeID
field is both the Primary Key and a Foreign Key, creating the 1..(0 or 1)
relation.
Now, I look at those two cases, which parallel my original examples -
[1] {EmployeePhoto:Employee}::{Employee:Department [in original example]}
(that is, many-to-one relationship, where Primary Key /= Foreign Key)
[2] {EmployeePhoto:Employee}::{EmployeePhoto:Employee [in original example]}
(that is, one-to-one relationship, where Primary Key = Foreign Key)
- and think you must be driving at some deeper point, which escapes me.
Anyway - I hope that helps...not sure I actually explained it all that
well, so ask further is you like.
Actually, Drew, you answered my original question very clearly and
succinctly. Thank you so much. But beginning with "Now then however..."
you began to lose me, because you seemed to be saying something much more
basic (that was in fact already implied in my question) - and yet, because
you know a LOT more about this stuff than I do, I think you are getting at a
more subtle point behind the (apparently) basic one. I just can't figure
out what it is. So, much as I hate to waste your time, if you'd like to
take another stab at that...
Best regards,
John
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
