I noticed that when I work with a new entity and invoke the related collection of entities, the runtime always tries to fetch data from the database. For example, imagine that we have Agency and Location tables (1:m). This code

var agencyEntity = new AgencyEntity();
agencyEntity.Locations.Add(new LocationEntity());

queries database for Locations:

exec sp_executesql N'SELECT [Test].[dbo].[Location].[Id], [Test].[dbo].[Location].[AgencyId], [Test].[dbo].[Location].[Street]  ...   FROM [Test].[dbo].[Location]  WHERE ( ( [Test].[dbo].[Location].[AgencyId] = @AgencyId1))',N'@AgencyId1 int',@AgencyId1=0

and this operation is redundant, because AgencyEntity is new.

I've found a workaround:

var agencyEntity = new AgencyEntity {AlreadyFetchedLocations = true};
agencyEntity.Locations.Add(new LocationEntity());

But it seems unnatural to use it in whole project. Do I have an alternative?

PS. I use the last version of LLBLGen (06-Apr-2009).

Thank you.

You could do this. Is the same result but no triggers lazy loading:

var agencyEntity = new AgencyEntity();
var theLocation = new LocationEntity();
theLocation.Agency = agencyEntity;

For v2.6 we did fix this, so it's a little odd you still see db acccess in that scenario. We'll look into it.

Reproduced... looking into it.

Looking into IF this has been added, it turns out it's not. I've mentioned on the forums once (http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=15181) that it has been added but it's not.

the reason seems to be that some customers do want this, and it would therefore break their code. (set the FK value, call the collection and you get the entities, it's a way to do filtered queries). We could have added a setting perhaps, but we didn't. I've made a change request for v3 to implement this with a setting (so default: you will get queries) so people who want this can port their code over and people who don't want this can switch it off. You should use the m:1 workaround David discussed above.