I'm using llbl 2.5-Final with SelfServicing and had a general question. I'm working on a process to load a bunch of data to a Postgre database and am trying to really streamline execution to get the speed up. I've noticed that when setting a field value that is on the foreign key side of any relationship, a query is performed to verify the value is allowed.

In this particular instance, I know that the id is valid (as I just finished creating it) and would like to disable this check. I saw the bypass for buildinvalidation, but that seems to be only related to data types, sizes, nulls, etc... I can't seem to find anyway to not perform this foreign key check.

Thanks for any help, and a big kudos to all of you, terrific product, I was blown away the first time using it - keep it up!

I've noticed that when setting a field value that is on the foreign key side of any relationship, a query is performed to verify the value is allowed.

As far as I know, no database query will be executed to check for the FK value.

How exactly are you setting the field, could you please post a code snippet?

I basically have a converter class that will create an entity and a list of xref values. Then once the entity is saved, a loop is done on the collection to set it's parent id. This is where I see a select query running that appears to be verifying this.

if (converter.DetailXrefCollection != null)
{
    foreach (CompanyDetailXref detailXref in converter.DetailXrefCollection)
    {
        detailXref.CompanyId = company.Id;
        converter.SaveDetailXref(detailXref);
    }
}

I know that I can add the xref entities to the collection and do a recursive save on it to handle this, I was simply trying different approaches to determine the fastest way.

When you debug the code, does the query get executed when running the following line?

detailXref.CompanyId = company.Id;

Most probably there are some manual code wired to an event that checks the database. (eg. FieldValidation code) LLBLGen Pro doesn't execute a query for the above code.

A wicked way to trace where the query is generated from is to turn the database server off before executing the above line then run the code, you should then get an excpetion with a stack trace that mught help us to find out where the query is generated from.

Well I've been pushed in a new direction and we're planning on just bulk loading to the database and doing any manipulation there. I'd still like to get this locked down and will work on a quick test and trace this afternoon/evening.

Thanks for the quick support!