VB.net can't find by string - vb.net

Using VB.net, the following snippet gives the error below.
Dim _account = Account.Find(Function(x As Account) x.AccountName = txtFilterAccountName.Text)
or similarly if I do
.SingleOrDefault (Function(x As Account) x.AccountName = txtFilterAccountName.Text)
will both give the error "The method 'CompareString' is not supported". If I make the same call searching for an integer (ID field) it works fine.
.SingleOrDefault (Function(x As Account) x.Id = 12)
So integer matching is fine but strings don't work Is this a problem with the VB.net templates?

No this is not a problem with Vb.Net templates.
The problem is that you are not using a normal LINQ provider. Based on your tag (subsonic) I'm guessing you're using a LINQ to SQL query.
The problem is that under the hood, this is trying to turn your code into an expression tree which is then translated into an SQL like query. Your project settings are turning your string comparison into a call in the VB runtime. Specifically, Microsoft.VisualBasic.CompilerServices.Operators.CompareString.
The LINQ2SQL generater in question or VB compiler (can't remember where this check is done off the top of my head) does not understand how to translate this to an equivalent bit of SQL. Hence it generates an error. You need to use a string comparison function which is supported by LINQ2SQL.
EDIT Update
It looks like the CompareString operator should be supported in the Linq2SQL case. Does subsonic have a different provider which does not support this translation?
http://msdn.microsoft.com/en-us/library/bb399342.aspx

The problem is with SubSonic3's SQL generator and the expression tree generated from VB.NET.
VB.NET generates a different expression tree as noted by JaredPar and SubSonic3 doesn't account for it - see Issue 66.
I have implemented the fix as described but it has yet to merge into the main branch of SubSonic3.

BlackMael's fix has been committed:
http://github.com/subsonic/SubSonic-3.0/commit/d25c8a730a9971656e6d3c3d17ce9ca393655f50
The fix solved my issue which was similar to John Granade's above.
Thanks to all involved.

Related

Documentation about functions used in SSRS

I will keep it as short as possible. ( Please take into consideration , that I am not familiar with c# programming / dll and such things. I have been mostly working in the Data Analysis world with python )
I have a report in SSRS in Visual Studio that I would like to add some embedded code.
And i am trying to call those functions that are available for the SSRS
Microsoft Documentation states that for those functions you could call them by given the specific class.
for example
Math.Floor()
https://learn.microsoft.com/en-us/sql/reporting-services/report-design/custom-code-and-assembly-references-in-expressions-in-report-designer-ssrs?view=sql-server-ver15
. For convenience, you can view the most commonly used functions in the Expression dialog box, where they are listed by category: Text, Date and Time, Math, Inspection, Program Flow, Aggregate, Financial, Conversion, and Miscellaneous. Less commonly used functions do not appear in the list but can still be used in an expression.
I am trying to use the lookup function in the code
by calling Miscellaneous.Lookup
but somehow I get an error that this class does not exist.
do you have any idea where is the API/DEV Documentation related to this. I cannot really find any documentation reference to that function.
If I try with Math.Floor(1) it actually works
another a little bit more complex code
public function a(byVal x as Integer) as String
if(x = 1 ) then
Return Math.Floor(1)
else Return 2
end if
end function
EDIT: ( Thanks #Timothy G. )
Miscellaneous.Lookup(1,1,"holaInLookup","DataSet1")
Still same error

LINQ, Visual Basic, & Reflection: capitalization of field names from queries returning anonymous type

Edited to answer my own question. This appears to be a LINQ/VB bug.
A simple LINQ query returning an anomymous type will sometimes change the field names specified in the query so as to capitalize them. Perhaps passing the result of the query as a parameter to a method call:
someThing.someMethod(From someStuff In stuffList _
Select text = someStuff.Name(), _
value = someStuff.Id
)
where someMethod has signature
Public Sub someMethod(ByVal list As IEnumerable(Of Object))
If you step into the execution of someMethod, and then examine the value of list in quickwatch, you may or see the field names as "text"&"value" or "Text"&"Value".
LINQ queries should not be changing the field names as specified in the query, so the correct behavior is fieldnames "text"&"value". Yet production builds of our application have the incorrect capitalization behavior (which can be determined indirectly), and debug builds have shown it both happening both ways at different times and/or for different developers' machines.
I've looked high & low for some feature of LINQ which controls this behavior, but now am virtually certain it is a bug. (msdn forum thread, MS Connect bug page)
This is likely to only cause a problem if you are using reflection, such as type.getfield() such as in
listItem = list.ElementAt(index)
itemTextField = listItem.GetType().GetField("text")
itemText = CType(itemTextField.GetValue(listItem),String)
If this happens to you, the workaround is to use overload of GetField with bindingflags to make it case-insensitive:
itemTextField = listItem.GetType().GetField("text", BindingFlags.IgnoreCase)
It must be pretty rare to encounter this bug, but maybe the next person will spend less time scratching their head if they find this info here.
=========original post===========
Getting different behavior in my debug build environment than in my coworkers' and our production envirnonment, relating to LINQ and reflection...
While running debug build of legacy code, the following code
Dim objectType As Type = obj.GetType()
Dim field As FieldInfo = objectType.GetField(name)
Dim prop As PropertyInfo = objectType.GetProperty(name)
results in Nothing for field & prop.
The value of obj is passed down from above and is the result of a LINQ query (it is a single element of the list generated by the query):
From bpt In CustomBProcessTypes Select text = bpt.Name(), value = bpt.Id
The value of name is also passed from above and is "Text" (note capitalization).
I can examine obj in the debugger and confirm that the fieldnames of the object created by the LINQ query are 'text' and 'value' (note lack of capitalization) which is what I would expect.
So failure to find the field by the capitalized name makes sense. However, our production builds and my coworkers builds do not have this problem.
Because calls to type.getfield(string) are expressly cas-sensitive, the only thing I can think of at this point is there must be some configuration of LINQ relating to auto-capitalization of column/fieldnames, and my environment is not set up the same as the others.
Using visual studio 2012. I don't know much of anything about LINQ, per se.
Anyone have any idea what could be going on here?
(NOTE: if I can get an opportunity, I'll have a coworker step through the relevant code and see if in their environment the object created by the linq query ends up with capitalized field names)
EDIT: I verified with a coworker in his debug build: his LINQ query creates a list of objects with field names "Text" and "Value", but on in my environment the LINQ query ends up with field names "text" and "value". The code is the same, but there must be something about how LINQ is configured in my environment which fails to auto-capitalize those field names, but which happens on their machines and in our production environment.
I suppose it is possible that some compiler settings are resulting in different capitalization. Normally this would make no difference because VB.NET is a case-insensitive language so obj.Text and obj.text both work just as well. But to use case insensitivity in reflection lookups, you need to specify it by including BindingFlags.IgnoreCase in the second parameter of GetField or GetProperty:
Dim field As FieldInfo = objectType.GetField(name,
BindingFlags.Public Or BindingFlags.Instance Or BindingFlags.IgnoreCase)
I'm confused as to where name is coming from, though. Some other code is getting the field name from reflection on the query? I didn't see where this was explained in your question.
I have answered my own question (insofar as is possible). Boils down to a bug in LINQ/vb.net.
Fully explained at top of original post (edited in). Hope this saves someone time in the future.

Query MongoDB using VB.NET - nullable types

The MongoDB C# driver supports queries on Nullable(Of T) according to this Jira ticket:
https://jira.mongodb.org/browse/CSHARP-483
However, I am having issues getting it working.
mycol.AsQueryable.Where(Function(p) p.MyNullableInteger = 3)
As instructed, I removed the .Value property from the query, however that breaks strict typing, so I had to remove my Option Strict On clause. It then compiled successfully however I would ideally like that clause back in.
The PredicateTranslator is throwing an exception as follows:
Unsupported where clause: (Boolean)(p.MyNullableInteger == (Nullable)3)
The actual Where clause expression generated by .NET is:
p => Convert((p.MyNullableInteger == ConvertChecked(3)))
I am using driver 1.5. My POCO class does register a classmap but the mapping does not reference the property here (it is just setting representation from String to ObjectId for my Id property).
Turns out this is only a bug in Visual Basic. It works fine in C#. I have created a Jira here: https://jira.mongodb.org/browse/CSHARP-542.
I'm also going to edit your question tags to include VB as opposed to c#.

VB.Net Linq to Entities Null Comparison - 'Is Nothing' or '= Nothing'?

We have several projects in VB.Net, using .Net Framework 4 and Linq to Entities for many of our SQL queries. Moving to EF is a new shift for us (been using it for about 4-6 months) and has the backing of upper management because we can code so much faster. We still use a lot of stored procs, but we even execute those through Linq to Entities as well.
I'm hoping to clear some confusion up and I can't find a direct answer that makes sense. We have some queries where we want records where a specific field has a NULL value. These are simple select queries, no aggregates or left joins, etc. Microsoft recommends the query look something like this MSDN Link:
dim query = from a in MyContext.MyTables
Where a.MyField = Nothing
Select a
I have several projects where I do exactly this and it works great, no warnings in the IDE. Recently a new project was created by another developer and when he did his null check like above, we all get this warning in the IDE:
Warning 1 This expression will always evaluate to Nothing (due to null propagation from the equals operator). To check if the value is null consider using 'Is Nothing'.
Comparing the projects, option explicit and option strict are on for each one. If we ignore the warning, we get the exact record set we are looking for when the app runs. The warning goes away if I change the = sign to IS. But why did this warning appear in one project and not others? It's confusing when even on MSDN there are examples using the equals operator.
Generated column should be a Nullable(Of T)
So you can check if that field has value or not like this:
dim query = from a in MyContext.MyTables
Where Not a.MyField.HasValue
Select a
I believe what you're seeing here is that MyField is a Nullable(Of T) type. Likely a primitive Integer, Single, etc ...
The reason you're seeing this warning is because the compiler promotes the normal equality operator for the primitive type to the Nullable(Of T) version. It essentially executes the following
Dim myField As Integer? = a.MyField
Dim other As Integer? = Nothing
If myField = other Then
...
End If
The issue though is that when Integer? has the value Nothing it won't compare equal to anything. Hence the above Where clause will always return False. The compiler is attempting to warn you about this problematic corner of Nullable(Of T) and push you to a Is Nothing check which will determine if a.MyField has a non-null value.
This blog article has a very detailed explanation of why this warning is being generated and all of the mechanics behind it. The article is written for C# but the basic premise is applicable to VB.Net as well.
http://blogs.msdn.com/b/abhinaba/archive/2005/12/14/503533.aspx
At least in LINQ to objects you can use this instead:
Nullable(Of Integer).Equals(a, b)
This works fine with both, either or none of the two values being Nothing.

Simple LINQ question - how to iterate through a group?

I need some help with a LINQ query in VB.Net, please.
I have this simple group statement:
Dim drivers = From d In DriversOwners _
Group d By Key = d.UnitNumber Into Group _
Select Key, DriverGroup = Group
This works, and returns me the data I need to work with. Now I want to iterate through the groups, using a For Each construct. like this:
For Each x In drivers
Next
However, the compiler is barking at me, telling me that the
"'x' is not accessible in this context because it is 'Friend'."
Anyone know what I am doing wrong here?
Thanks in advance.
After digging and digging, I finally found the answer to this problem. Talk about obtuse!
Enabling LINQ in a .NET Framework 3.5 Project
When you move a project to .NET
Framework 3.5, a reference to
System.Core and a project-level import
for System.Linq (in Visual Basic only)
are added automatically. If you want
to use LINQ features, you must also
turn Option Infer on (in Visual Basic
only) [my emphasis].
When I changed the target framework from 2.0 to 3.5, Visual Studio automatically added the System.Core assembly, and automatically imported the System.Linq namespace. Now why in the world did it not also set Option Infer to "On" as well?
http://msdn.microsoft.com/en-us/library/bb398197.aspx
Looks to me like the variable x was declared earlier - as a class field, a method parameter, or a local variable.
Am I right?
I'm not sure if you've solved this or not. I had the exact same problem today and what ended up working for me was to not use a single-letter variable in the For Each loop. My code was the same as yours:
For Each x In a
...
Next
When I changed the code to the following it worked:
For Each retVal in a
...
Next
I also found the same 'Friend' error behavior for any single-letter variable.
I have no idea why it behaves this way, but I thought I'd pass this along in case this question is still out there.