If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Where to define Relationships - FE or BE?
Where is it best to define database Relationships.
I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? -- Regards Tom |
#2
|
|||
|
|||
Where to define Relationships - FE or BE?
ThomasAJ wrote:
Where is it best to define database Relationships. I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? All relationships in the front end do is create default join lines in new queries (and perhaps documentation). -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com |
#3
|
|||
|
|||
Where to define Relationships - FE or BE?
On Fri, 24 Oct 2008 17:01:01 -0700, ThomasAJ
wrote: BE. And you need to enforce them. -Tom. Microsoft Access MVP Where is it best to define database Relationships. I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? |
#4
|
|||
|
|||
Where to define Relationships - FE or BE?
Are you implying that BE relationships do not?
-- Regards Tom "Rick Brandt" wrote: ThomasAJ wrote: Where is it best to define database Relationships. I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? All relationships in the front end do is create default join lines in new queries (and perhaps documentation). -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com |
#5
|
|||
|
|||
Where to define Relationships - FE or BE?
Can you please expand on "need to enforce them" just a little.
-- Regards Tom "Tom van Stiphout" wrote: On Fri, 24 Oct 2008 17:01:01 -0700, ThomasAJ wrote: BE. And you need to enforce them. -Tom. Microsoft Access MVP Where is it best to define database Relationships. I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? |
#6
|
|||
|
|||
Where to define Relationships - FE or BE?
ThomasAJ wrote:
Are you implying that BE relationships do not? Nope -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com |
#7
|
|||
|
|||
Where to define Relationships - FE or BE?
On Fri, 24 Oct 2008 17:01:01 -0700, ThomasAJ
wrote: Where is it best to define database Relationships. I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? The relationships can only exist and be enforced in the backend; that's where the tables are. Relationships established in a DIFFERENT database (a frontend) would have no way of being enforced, since someone could open the backend directly, or from a different frontend. So: relationships are *only* in the backend. Anything in the frontend is just for documentation or information, not for controlling the data. -- John W. Vinson [MVP] |
#8
|
|||
|
|||
Where to define Relationships - FE or BE?
relational joins that are not enforced are basically cosmetic - they do
nothing to control or protect the table data. open your database to the database window, then open the Relationships window. double click on any "line" connecting fields in two tables, to open the Edit Relationships dialog. the left column shows the "parent" table and its' primary key (the "left side" of the relationship); the right column shows the "child" table and its' foreign key that corresponds to the primary key in the parent table (the "right side" of the relationship). underneath are three options: Enforce Referential Integrity (which should always be checkmarked) Cascade Update Related Fields (which is usually only necessary when the primary/foreign key field(s) hold data that has "real world" meaning which may be changed by the user) Cascade Delete Related Records (which is useful for getting rid of child records automatically when the related parent record is deleted, BUT it should be activated **only after careful thought to the ramifications in each specific situation** because automatically deleted records are like all other deleted records - gone forever) if you need further information on the reasons for enforcing referential integrity on relational joins, suggest you read up/more on the principles of relational design. hth "ThomasAJ" wrote in message ... Can you please expand on "need to enforce them" just a little. -- Regards Tom "Tom van Stiphout" wrote: On Fri, 24 Oct 2008 17:01:01 -0700, ThomasAJ wrote: BE. And you need to enforce them. -Tom. Microsoft Access MVP Where is it best to define database Relationships. I have an old split database that has some relationships in the Back End but also others in the Front End. I presume it should be the BE and that the FE ones have no effect or do they? |
Thread Tools | |
Display Modes | |
|
|