views:

41

answers:

2

In MS Access 2003 I have a form whose record source is equal to a query that involves an INNER JOIN. The join is between a location table and a container table. Containers are objects that are stored in specific locations each location and container are specified by ID values.

SELECT DISTINCTROW Container.Container_ID, Location.Location_ID
FROM Location INNER JOIN Container 
ON Location.[Location_ID] = Container.[Location_ID]

What I am trying to figure out is this …. When I delete a record (using the form navigation controls) in the form based on the above query which tables are affected? Are records in the Container and Location tables deleted or is it just in the location table? Thanks!

A: 

It depends on whether or not you have a relationship set up between the tables, and your setting for "Cascade Delete Related Tables" is turned on for that relationship.

If you have a relationship, and Cascading Deletes are turned on, it will definitely delete the records in the associated table.

If Referential Integrity is enforced between the two tables, Access will complain if you try to delete a parent record without first deleting all of the associated child records.

It is unclear to me what happens in a form if both tables are present in a query for the form and a deletion is requested, and cascading deletes is turned off. But that would be easy enough to test.

http://office.microsoft.com/en-us/access/ha011739511033.aspx

Robert Harvey
The form is displaying data from two tables, Location and Container. My goal is to delete only the container record since a location may have multiple containers, yet a container can only have one location. I am wondering if perhaps the record source SQL needs to be changed to make sure sure that the container is deleted rather than the location.
webworm
+1  A: 

Without a relationship defined, you will delete the current row from Container and leave Location unchanged.

However, I think you should add a relationship and enforce referential integrity to assure you can't delete a location which still has a container stored there. Otherwise you could wind up with a Container record which refers to a Location_ID which no longer exists. The relationship may not help with this form and query, but it can safeguard against mistakes in other situations.

There are other ways to design your form which would make it easier to understand which record will be deleted from where. You could base a main form on Location and include a subform based on Container. In the properties set Location_ID as the link master/child field. Then for the Location_ID displayed in the main form, all the containers stored at that location will be displayed in the subform. Use the subform to delete whichever container you want.

HansUp
How did you determine that the row from the Container table would be deleted and not the record from Location? Not that I doubt you, rather I am trying to understand why the Container table is the one effected. Thanks for the design suggestion. This form was created by someone else and I have not come across a situation like this before. In the past I have kept form record sources to a single table when deletes were allowed. Unless I was going to generate the DELETE statement and execute via SQL. Thank you for the help.
webworm
@webworm I wanted to understand how DISTINCTROW affected your situation, so I built the tables, query and form to find out. My answer was based on my testing. Like you I prefer to base deletes on a single table source, rather than 2 or more joined together. If you decide not to redesign the form, please do add the relationship anyway. It's just good practice, IMO.
HansUp
Thanks for explaining that. Multi-table record sources sure make things interesting.
webworm