LLBLGen Pro Version: 5.5.3

When using the QueryFactory .Create() method to generate a new DynamicQuery, if you only give one table to the .From() method, when you try to fetch, it will throw an exception stating "The multi-part identifier 'xxxxx' could not be bound.

The following code throws the exception:

var paymentHeadersQuery = _unityPaymentsQueryFactory.Create()
                                                                                     .From(_unityPaymentsQueryFactory.PaymentHeader)
                                                                                     .Where(PaymentHeaderFields.CheckId.Equal(checkId))
                                                                                     .Select(() => new
                                                                                     {
                                                                                         Id = PaymentHeaderFields.Id.ToValue<int>(),
                                                                                         BillNumber = PaymentHeaderFields.BillNumber.ToValue<string>(),
                                                                                         CheckId = PaymentHeaderFields.CheckId.ToValue<int>()
                                                                                     });

var paymentHeaders = _unityPaymentsAccessAdapter.FetchQuery(paymentHeadersQuery);

Exception that is thrown: SD.LLBLGen.Pro.ORMSupportClasses.ORMQueryExecutionException: 'An exception was caught during the execution of a retrieval query: The multi-part identifier "Unity_Payments.dbo.tbl_PaymentHeader.CheckId" could not be bound. The multi-part identifier "Unity_Payments.dbo.tbl_PaymentHeader.Id" could not be bound. The multi-part identifier "Unity_Payments.dbo.tbl_PaymentHeader.BillNumber" could not be bound. The multi-part identifier "Unity_Payments.dbo.tbl_PaymentHeader.CheckId" could not be bound.. Check InnerException, QueryExecuted and Parameters of this exception to examine the cause of this exception.'

The following code does not throw the exception:

var paymentHeadersQuery = _unityPaymentsQueryFactory.PaymentHeader
                                                                                     .Where(PaymentHeaderFields.CheckId.Equal(checkId))
                                                                                     .Select(() => new
                                                                                     {
                                                                                         Id = PaymentHeaderFields.Id.ToValue<int>(),
                                                                                         BillNumber = PaymentHeaderFields.BillNumber.ToValue<string>(),
                                                                                         CheckId = PaymentHeaderFields.CheckId.ToValue<int>()
                                                                                     });

var paymentHeaders = _unityPaymentsAccessAdapter.FetchQuery(paymentHeadersQuery);

From wrote:

To specify the source of a query, QuerySpec offers the query.From() method on a QuerySpec derived object. In many queries it's not necessary to use From(): only in DynamicQuery instances where it's not clear what the source is by looking at the projection, or when you want to specify Joins, From() is required.

Don't use From(), and instead provide a source for the query, as you did in the later example.

Indeed. It can figure out the 'from' clause of the query from the fields in the projection.

Alright. That makes sense then.

Is it possible to not allow putting only one table in the .From() clause, or at least a more descriptive Exception message when you do? The existing message just doesn't seem to describe the problem.

The thing is that you actually can use it, and should in some cases like mentioned here.

At the end, the sql is constructed based on the expression tree you gave it using QuerySpec. The error is accurate as it describes the error in the sql generated. It's the same as if you use an incorrect join, or an incorrect field in an expression, the error comes out in the sql.