Don't know what's wrong here, when I run the application it says "Specified method is not supported" pointing at "var result in query" in foreach loop. Please help...
var query = from c in entities.Customer
select c.CustomerName;
List<string> customerNames = new List<string>();
foreach (var result in query)
{
customerNames.Add(result.ToString());
}
EDIT: using ToList() also gives the same error.
The reason for your error is scope, which is what the "method not supported" error is telling you.
This usually happens when using a Linq to [fill in the blank] ORM. So, I'm guessing your entities must be from an ORM tool, something like Entity Framework, and you are using something like Linq to Entities.
When using linq your query is not enumerated out until you access it, which for an ORM means hitting the database or other data repository. This delayed action can cause some strange behavior if you do not know it is there, such as this error.
But, you have local (non-linq) code and your query intertwined, so the linq to [] compiler does not know how to handle your local code when compiling the linq code. Thus the "method not supported" error - it is basically the same as referencing a private method from outside of the class, the method you called is unknown in the current scope.
In other words the compiler is trying to compile your query and hit the database when you do the result.ToString(), but does not know anything about the private variable of CustomerNames or the foreach method. The database logic and the local object logic have to be kept separate - completely resolve the database query results before using locally.
You should be able to write it like this:
var customerNames = entities.Customer.Select(c => c.CustomerName).ToList();
If you have to keep the foreach (for more complicated logic, not for this simple of an example) you still need to resolve the Linq to [] portion (by forcing it to enumerate the query results) prior to involving any non-linq code:
var query = from c in entities.Customer
select c.CustomerName;
var qryList = query.ToList();
List<string> customerNames = new List<string>();
foreach (var result in qryList)
{
customerNames.Add(result.ToString());
}
Can you try using just the ToList() method instead of the foreach?
List<string> customerNames = query.ToList();
If the problem is not ToString() as Gart mentioned my second suspicious falls in c.CustomerName. Is this a custom property in your partial class?
Also, the stacktrace of the exception must surly show what is the unsupported method.
Try removing .ToString() and see if this will work:
foreach (var result in query)
{
customerNames.Add(result);
}
Seems like that the root of the problem lies deep inside LINQ-to-SQL query translation mechanism. I suppose the translation engine tries to translate .ToString() into SQL and fails there.
try this
var query = from c in entities.Customer
select c.CustomerName;
List<string> customerNames = new List<string>();
query.ToList().ForEach(r=>customerNames.Add(r));
Related
I'm trying to perform a LIKE clause in an entity query. The examples I've seen use dynamic linq to do this kind of thing, but my code...
var query = context.StudySet
.Where("it.PatientName LIKE #patientName", new ObjectParameter("patientName", patientName);
...gives me a System.Linq.Dynamic.ParseException with
Additional information: Expression of type 'Boolean' expected
context is a DbContext from EF 6 code-first, patientName is a string
Please tell me what's wrong with my code?
if you want use DynamicLINQ you need change your code like this
var query = context.StudySet.Where("it.PatientName.Contains(#0)", patientName);
because DynamicLinq can't parse LIKE operator
I've realised my mistake.
I had assumed the method to pass the query was part of Dynamic Linq but actually it's just a variant of the standard Where method on ObjectQuery. If I get the ObjectContext from my (code first) DbContext it's all good.
ObjectContext objectContext = ((IObjectContextAdapter)context).ObjectContext;
ObjectSet<Study> studySet = objectContext.CreateObjectSet<Study>();
var query = studySet.
Where("it.PatientName LIKE #patientName", new ObjectParameter("patientName", patientName));
I don't know of a way to use like with a LINQ query, but you could use a raw SQL query:
var query = context.StudySet.SqlQuery(
"select * from StudySet where PatientName LIKE #patientName",
new SqlParameter("#patientName", patientName));
I am using LinqPad to test my query. This query works when the LInqPad connection is to my database (LInq to SQL) but it does not work when I change the connection to use my Entity Framework 5 Model.dll. (Linq to Entity). This is in C#.
I have two tables called Plan and PlanDetails. Relationship is one Plan to many PlanDetails.
var q = from pd in PlanDetails
select new {
pd.PlanDetailID,
ThePlanName = (from p in this.Plans
where p.PlanID == pd.PlanID
select p.PlanName)
};
var results = q.ToList();
q.Dump(); //This is a linqpad method to output the result.
I get this error "NotSupportedException: Unable to create a constant value of type 'Domain.Data.Plan'. Only primitive types or enumeration types are supported in this context." Any ideas why this only works with Linq to SQL?
basically it means you are using some complex datatype inside the query for comparison.
in your case i suspect from p in this.Plans where p.PlanID == pd.PlanID is the culprit.
And it depends on DataProvider. It might work for Sql Data Provider, but not for SqlCE data Provider and so on.
what you should do is to convert your this.Plans collection into a primitive type collection containing only the Ids i.e.
var integers = PlanDetails.Plans.Select(s=>s.Id).ToList();
and then use this list inside.
var q = from pd in PlanDetails
select new {
pd.PlanDetailID,
ThePlanName = (from p in integers
where p == pd.PlanID
select pd.PlanName)
};
I got this error when i was trying to null check for a navigational property in the entity framework expression
I resolved it by not using the not null check in the expression and just using Any() function only.
protected Expression<Func<Entities.Employee, bool>> BriefShouldAppearInSearchResults(
IQueryable<Entities.Employee> briefs, string username)
{
var trimmedUsername = NameHelper.GetFormattedName(username);
Expression<Func<Entities.Employee, bool>> filterExpression = cse =>
cse.Employee.Cars.All(c =>
c.Employee.Cars!=null && <--Removing this line resolved my issue
c.Employee.Cars.Any(cur => cur.CarMake =="Benz")));
return filterExpression;
}
Hope this helps someone!
This is a Linqpad bug if you like (or a peculiarity). I found similar behaviour myself. Like me, you may find that your query works with an ObjectContext, but not a DbContext. (And it works in Visual Studio).
I think it has to do with Linqpad's inner structure. It adds MergeAs (AppendOnly) to collections and the context is a UserQuery, which probably contains some code that causes this bug.
This is confirmed by the fact that the code does work when you create a new context instance in the Linqpad code and run the query against this instance.
If the relationship already exists.
Why not simply say.
var q = from pd in PlanDetails
select new {
pd.PlanDetailID,
ThePlanName = pd.Plan.PlanName
};
Of course i'm assuming that every PlanDetail will belong to a Plan.
Update
To get better results from LinqPad you could tell it to use your own assembly (which contains your DbContext) instead of the default Datacontext it uses.
I have created a linq query that returns my required data, I now have a new requirement and need to add an extra field into the returned results. My entity contains an ID field that I am trying to map against another table without to much luck.
This is what I have so far.
Dictionary<int, string> itemDescriptions = new Dictionary<int, string>();
foreach (var item in ItemDetails)
{
itemDescriptions.Add(item.ItemID, item.ItemDescription);
}
DB.TestDatabase db = new DB.TestDatabase(Common.GetOSConnectionString());
List<Transaction> transactionDetails = (from t db.Transactions
where t.CardID == CardID.ToString()
select new Transaction
{
ItemTypeID= t.ItemTypeID,
TransactionAmount = t.TransactionAmount,
ItemDescription = itemDescriptions.Select(r=>r.Key==itemTypeID).ToString()
}).ToList();
What I am trying to do is key the value from the dictonary where the key = itemTypeID
I am getting this error.
Local sequence cannot be used in LINQ to SQL implementations of query operators except the Contains operator.
What do I need to modify?
This is a duplicate of this question. The problem you're having is because you're trying to match an in-memory collection (itemDescriptions) with a DB table. Because of the way LINQ2SQL works it's trying to do this in the DB which is not possible.
There are essentially three options (unless I'm missing something)
1) refactor your query so you pass a simple primitive object to the query that can be passed accross to the DB (only good if itemDescriptions is a small set)
2) In your query use:
from t db.Transactions.ToList()
...
3) Get back the objects you need as you're doing, then populate ItemDescription in a second step.
Bear in mind that the second option will force LINQ to evaluate the query and return all transactions to your code that will then be operated on in memory. If the transaction table is large this will not be quick!
DynamicObject LINQ query with the List compiles fine:
List<string> list = new List<string>();
var query = (from dynamic d in list where d.FirstName == "John" select d);
With our own custom class that we use for the "usual" LINQ compiler reports the error "An expression tree may not contain a dynamic
operation":
DBclass db = new DBclass();
var query = (from dynamic d in db where d.FirstName == "John" select d);
What shall we add to handle DynamicObject LINQ?
Does DBClass implement IEnumerable? Perhaps there is a method on it you should be calling to return an IEnumerable collection?
You could add a type, against which to write the query.
I believe your problem is, that in the first expression, where you are using the List<>, everything is done in memory using IEnumerable & Link-to-Objects.
Apparently, your DBClass is an IQueryable using Linq-to-SQL. IQueryables use an expression tree to build an SQL statement to send to the database.
In other words, despite looking much alike, the two statements are doing radically different things, one of which is allowed & one which isn't. (Much in the way var y = x * 5; will either succeed or fail depending on if x is an int or a string).
Further, your first example may compile, but as far as I can tell, it will fail when you run it. That's not a particular good benchmark for success.
The only way I see this working is if the query using dynamic is made on IEnumerables using Link-to-Objects. (Load the full table into a List, and then query on the list)
i have a problem with some data i retrievied from db with linq.
When I try to access data I obtain the following exception:
System.ObjectDisposedException : The istance of ObjectContext was deleted and is not possible to use it again for action that need a connection.
This is the code:
using (ProvaDbEntities DBEntities =
new ProvaDbEntities(Utilities.ToEntitiesConnectionString()))
{
ObjectQuery<site> sites = DBEntities.site;
IEnumerable<site> q = from site in sites
select site;
{
ObjectQuery<auction> auctions = DBEntities.auction;
IEnumerable<auction> q1 = from auction in auctions
where auction.site == this.Name
select auction;
IEnumerable<IAuction> res = q1.Cast<IAuction>();
return res;
}
}
catch(Exception e)
{
throw new UnavailableDbException("[GetAuctions]" + e.Message);
}
Someone can help me???
Tanks
Fabio
Yes - you're returning a result which will be lazily evaluated - but you're disposing of the data context which would be used to fetch the results.
Options:
Load the results eagerly, e.g. by calling ToList on the result
Don't dispose of the context (I don't know what the situation is in the Entity Framework; you could get away with this in LINQ to SQL, but it may not be a good idea in EF)
Dispose of the context when you're finished with the data
In this case I'd suggest using the first option - it'll be safe and simple. As you're already filtering the results and you're casting to IEnumerable<IAuction> anyway, you're unlikely to get the normal downsides of materializing the query early. (If it were still IQueryable<T>, you'd be throwing away the ability to add extra bits to the query and them still be translated to SQL.)