Error querying a table with the Data Entity Framework
I am getting an error that is driving me nuts. Here is the deal;
I run this query without any problems:
var jobrows = (from p in tx.job_mst where p.wbs_obj_nbr == 1 select p).ToList();//check the output
if (jobrows.Count() == 0)If the query doesn't return any rows, everything is fine, and my count will be 0.
But then I run another, which is almost the same
var jobtypes = (from p in tx.job_type_avt where p.job_type_cd == wbs.PRART select p).ToList();
if (jobtypes.Count == 0)Here the code blows up with an error and doesn't even reach the if statement:
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<code /><message xml:lang="en-US">Resource not found for the segment 'job_type_avt'.</message></error>The only difference between the two tables is that the primary key for the first one is composed of int members, while the second one is a string (char(2) in the DB). I am not sure this is relevant, but just in case. I am just querying the table, not deleting or anything like that.Can somebody provide an idea of what's going on in here, and what I may be doing wrong?Thanks in advance!
Réponses
In the firsr query the Linq to URI translator does not find all the keys, so it turns the predicate into a filter expression. So essentially this query is returning the set of all job_mst items filtered by p.wbs_obj_nbr == 1. In this case since there are no objects that satisfy the predicate, an empty set is returned.
For the second query, the Linq expression has included all the keys in the predicate, so a URI that is looking for one specific entity is created. The semantics for this differ slightly in that this query will only return a single entity – and if that specific entity does not exist a HTTP error 404 (Resource not found) will be raised.
We did it this way because we wanted to preserve proper REST semantics. That said, this can be nasty since little subtle changes in the query can change the semantics. i.e. let’s say the C# compiler added an implicit cast in the predicate, then the LINQ translator would make a filter instead on a key predicate.
For vNext we are probably going to add a property to the client library that allows the user to specify that they want 404 error cases returned as empty sets with no exception being thrown. Unfortunately can’t help you much now, but just wanted to let everyone know we are aware of this issue.
Toutes les réponses
Can you post the URIs being generated for the two Linq queries? You can get this by calling ToString on the query object.
Thanks - Andy
Hi, Andy:
Thanks for the quick response.
Here are the two URIs:
1. "http://localhost/IntegrationBus.Services.Data.ODS/ODSDataService.svc/job_mst()?$filter=wbs_obj_nbr eq '133'"
2. "http://localhost/IntegrationBus.Services.Data.ODS/ODSDataService.svc/job_type_avt('SH')"Thanks, Enrique
In the firsr query the Linq to URI translator does not find all the keys, so it turns the predicate into a filter expression. So essentially this query is returning the set of all job_mst items filtered by p.wbs_obj_nbr == 1. In this case since there are no objects that satisfy the predicate, an empty set is returned.
For the second query, the Linq expression has included all the keys in the predicate, so a URI that is looking for one specific entity is created. The semantics for this differ slightly in that this query will only return a single entity – and if that specific entity does not exist a HTTP error 404 (Resource not found) will be raised.
We did it this way because we wanted to preserve proper REST semantics. That said, this can be nasty since little subtle changes in the query can change the semantics. i.e. let’s say the C# compiler added an implicit cast in the predicate, then the LINQ translator would make a filter instead on a key predicate.
For vNext we are probably going to add a property to the client library that allows the user to specify that they want 404 error cases returned as empty sets with no exception being thrown. Unfortunately can’t help you much now, but just wanted to let everyone know we are aware of this issue.
Thanks, Andy. We will keep this in mind.
For the moment we'll have to hack our code a little bit, and hope to hear from you guys again.

