Hi all,

Ive created a collection of entities and I am trying to remove an item from one entity

Clients.Items(0).DboTblCdclientResponseOther.Items.RemoveAt(Me.lbOther.SelectedIndex)

However even though the item count reduces by one, when I save the collection this record does not get deleted.

I have set the AllowRemove property = True. Also when I deub the object its ContainsDirtyContents property always = false.

Is it possible to delete a record this way.

Sean

removing an entity from a collection doesn't delete the entity from the db. This because it is an ambiguistic action: do you want to reduce the resultset of a fetch with 1 entity or do you want to remove the entity from the db? So if you want to remove the entity from the db, use a unitofwork and add the entity to delete to that unitofwork and after you're done, commit the unitofwork.

Thanks Otis

Yes I wanted to remove that entity from the db. I did add this entity to be removed to a new instance on the entity then used adaptor.DeleteEntity to remove it.

I just thought saveentitycollection would delete a record if it was removed from the collection.

Sean

Hi,

Is there a 'best practice' for removing entities from collections? I am looking at 'tagging removes with a flag' or 'cleaning the whole collection and re-inserting every save'.

which is better?

are there other options?

thanks

ian

What do you want to achieve? Just remove the entity from a collection? Or deleting it from the db?

I want to remove some but not all entities from the collection and the db. Transactionally. It is that scenario when a list arrives in a file and the new list must be made up of the contents of the file update/insert/delete from the collection and the db (and save a version of the old list for audit).

thanks

Please execuse me, I'm not sure what are you trying to do. But in general if you want to mark Entities for deletion, insertion and updates, and commit all of those actions in one Transaction, you should use UnitOfWork.

Check "Using the generated code -> Adapter/SelfServicing -> Unit of work and field data versioning" in the LLBLGen Pro documentation

yes, and that says:

Sometimes actions on entities span a longer timeframe and / or multiple screens. It's then often impossible to start a database transaction as user-interaction during a transaction should be avoided. To track all the changes made and to persist them in one transaction can then be a tedious task. With the UnitOfWork class this can be solved. The UnitOfWork class lets you collect actions on entities or collections of entities and can perform these actions in one go.

note: "impossible to start a database transaction". so a unit of work and a transaction are quite different things. I need transactions.

the transactions section uses code like

transactionManager.Add(newOrder);

I thought there might be some special property of the sort of relationship that neccessitated using UOW instead of transactions. If i can use a transaction I will cause i really want the changes to be done in units.

You can start the database transaction just before you call the UOW commit() method. So Transactions and UOW can work together.

Also please refer to the following thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=4864

I think I get that. To make sure I understand: when we use a transaction we could as well remove the UOW and just use the transaction directly. The UOW is used to group work in a non transactional way.

In short I don't get what value the UOW adds when there is a transaction. Did I miss something?

The reason behind inventing the UOW was: "Sometimes actions on entities span a longer timeframe and / or multiple screens. It's then often impossible to start a database transaction as user-interaction during a transaction should be avoided. To track all the changes made and to persist them in one transaction can then be a tedious task. With the UnitOfWork2 class this can be solved. The UnitOfWork2 class lets you collect actions on entities or collections of entities and can perform these actions in one go."

So nothing is done to the database when you start adding objects inside a UOW. Until you call UOW.Commit(), passing in the parameters a DataAccessAdapter object (if you are using the Adapter scenario), or a Transaction object (if you are using SelfServicing).

Anyway the Commit() method starts a database transaction to execute all its actions within, only if there was no transaction already started in the passed parameter.

And please not the Commit method only commits a transaction if it was created inside it. Otherwise it will just excute the database actions.

So the following scenario is valid: 1- You start database transaction 2- Perform some database actions // outside a UOW 3- Call UOW.Commit() // which uses the previous transaction to execute its actions 4- Perform some database actions // outside a UOW 5- Commit or Roolback your database transaction. // which will physically commit or rollback every action excuted within the context of this transaction including those excecuted from within the UOW.

Ok, i get that. Handy.

Thx.