Associating three entities in a m:n relationship, e.g., employee, department, dept_employee, is straightforward enough. However, I'm stuck on ways to remove an association and delete the (dept_employee) db record.

When the records exist in the db there is no problem because the bridging entity dept_employee can be referenced from each of the parent entities using a prefetch path.

but ...how can I work with entities that are new and IDs that are 0.

Here's a scenario. Employees are entered, Departments are entered, the user clicks on an employee and is presented with a list of departments and uses a checkbox to assign the employee to the chosen department. If one is selected, create a new dept_employee entity, assign the employee and department and save.

What can I do if they decide to change department BEFORE the data is saved. I can't find a solution to de-referencing the first dept_employee entity and creating a new one.

In this scenario, an employee can work for at most one department.

In my 'real world' scenario I have Passenger and Service and a bridging entity ServicePassenger with two columns being the FKeys from both parent, which together form the PKey. In this scenario there can be any number of passengers assigned (and de-assigned) to (from) a service.

I can't for the life of me find a solution to this vexing problem. Any help appreciated.

Maybe I am missing the point, but when you say

What can I do if they decide to change department BEFORE the data is saved. I can't find a solution to de-referencing the first dept_employee entity and creating a new one.

is it not possible to delete the row is in question in the dept_employee table - I am assuming that you have by now saved the record - mentioned previously by you.

Or is it that you have not saved to the DB, you want to 'delete' the row whilst still in memory.

Yes, delete the row whilst still in memory. But as it is new - Service, Pasenger and ServicePassenger are all new - there is no way of uniquely referencing the in-memory record to be removed.

All I have are two fields in ServicePassenger, Service_ID and Passenge_ID, both of which of course get their values from their as yet unsaved parents, so all 0s and no way out.

I'm figuring that I just don't have enough information to do this.

I'll go with servicepassenger.ObjID, store that in table used as a datagrid datasource hidden column. If servicepassenger has an empty ObID and is checked in the grid then it needs creating, if it has an ObjID then this can be retrieved by looping through the entity collection. A copy of the table will tell me if it was checked before but now is unchecked, so remove it. If I need to remove it from the collection then no problem using above to retrieve it by ObjID and it's index.

I'm sure this will work OK.

CliffH

The way I have done this is some of my projects is some thing like this:

1. Get First Parent - Service
2. Get seceond Parent - Passenger

Display, accept users action indicating association between the two

User clicks 'Save'

1. 'New' the ServicePassenger entity and save.

This allows the user the flexibility of 'experimenting' and the code is simplified.

Methods such as (see documentation on GetDependingRelatedEntities, GetDependentRelatedEntities and SetRelatedEntity, UnSetRelatedEntity methods), could help, but leaving the creation of the entity until the last moment I feel would simply coding.

Just a suggestion

Hi

In this scenario, an employee can work for at most one department.

That should have led you to adopting a simple fk without an intermediate table. You should avoid those extra tables when not needed because they are indeed quite painful to deal with.

Then I agree you should leave the creation of the entity to save to when you really want to do so.

Now, I'm not sure to understand why you can't unset your relation table entity.

if your department change, can't you do myRelatedEntity.Department = myNewDepartment?

I once thought the readonly nature of pkside related entity properties were a problem. But if you look at the generated code, you'll see that the events like those mentioned by sparmar are always fired and result in an entity sync.

For instance, the collections are all read only, but the ParentEntity property of the child entities from withing the collection are editable.

If you want to do a myCollec.Remove(MyChild), then MyChild.Parent = SomeOtherParent (replacement) / SomeJunkTempParent (deletion) should do the job

Jessynoo wrote:

That should have led you to adopting a simple fk without an intermediate table. You should avoid those extra tables when not needed because they are indeed quite painful to deal with.

Actually, espesially in an HR app, using a table like this is common. The association table also have effective date and term date. This keeps a job history of the employee as is required in an HR system.

I have also seen this in financials apps in certain circumstances. Many times there is a difference between the business relationship and the physical data. Alot of times views are used to simplify these relationships.

BOb

In this scenario, an employee can work for at most one department.

This keeps a job history of the employee as is required in an HR system

Then I guess you filter on the dates to get the current department right?

Now, about what I said previously, did you find ways to unset a not saved yet relation?