Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Bugs & Issues> Using DynamicQuery Create method with only one table throws Exception
 

Pages: 1
Bugs & Issues
Using DynamicQuery Create method with only one table throws Exception
Page:1/1 

  Print all messages in this thread  
Poster Message
bdavis
User



Location:

Joined on:
23-Jan-2019 13:46:45
Posted:
6 posts
# Posted on: 27-Jun-2019 16:04:26.  
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:
Code:

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:
Code:

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);

  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14531 posts
# Posted on: 28-Jun-2019 00:24:56.  
From the Docs 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.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37645 posts
# Posted on: 28-Jun-2019 09:10:17.  
Indeed. It can figure out the 'from' clause of the query from the fields in the projection.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
bdavis
User



Location:

Joined on:
23-Jan-2019 13:46:45
Posted:
6 posts
# Posted on: 28-Jun-2019 13:24:23.  
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.


  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8088 posts
# Posted on: 01-Jul-2019 06:22:58.  
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.
David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.