Linq and Implicit Conversions

[rrjii2000]

I'm trying to figure out how to use Linq and I keep getting this error message.

'Option Strict On requires all variable declarations to have an 'As' clause.'

Imports System.Linq
Imports System.Linq.Expressions
Imports System.Data.linq
Imports System.Data.Linq.Mapping



Dim MGWells = From MeterGroup In myMeterGroups _
                      Where MeterGroup.RecordType.Trim.Substring(0, 1) = "7" _
                      Order By MeterGroup.UniversalID _
                      Select MeterGroup.UniversalID

MeterGroup is my item class
and myMeterGroups is an instance of my Collection Class

The way I understand it, when setting up a Linq object you use an implicit type and the compiler will figure out what you're trying to do.

I have added refs for system.core and system.data.linq

Any Ideas?

[Phil Weber]

Try adding Option Infer On at the top of the file, or turning it on in the project's properties.

[rrjii2000]

Thanks Phil, that solved my first problem. But now I'm having a hard time making this whole thing work.

<Collection class>

 Public Function GetWells() As Object

        Dim MGWells = From item In Me
                     Where item.RecordType.Trim.Substring(0, 1) = "7" _
                     Order By item.UniversalID _
                     Select item.UniversalID

        MGWells = From item In Me _
                      Where item.RecordType.Trim.Substring(0, 1) = "7" _
                      Order By item.UniversalID _
                      Select item.UniversalID

        Return MGWells

    End Function

<form class>

 Public Sub CreateQuere()
       
        Dim myWells As Object = myMeterGroups.GetWells   ' calls the GetWells function (loads linq)
        
        For Each item As MeterGroup In myWells  ' ERROR myWells is an Object wich is not a collction type
            'iterate through items
        Next

    End Sub

I'm having trouble iterating through the linq collection, the above example gives me the 'object is not a collection type Error' and when I try and do it the other way and keep everything in my form class I still get Errors


'the other way'
<Form Class>

 Dim MGWells = From item In myMeterGroups
                     Where item.RecordType.Trim.Substring(0, 1) = "7" _
                     Order By item.UniversalID _
                     Select item.UniversalID

        MGWells = From item In myMeterGroups _
                      Where item.RecordType.Trim.Substring(0, 1) = "7" _
                      Order By item.UniversalID _
                      Select item.UniversalID

        For Each Item As MeterGroup In MGWells  ' ERROR MGWells is string and cant be converted to metergroups
         ' do stuff
        Next

[rrjii2000]

 Dim MGWells = From item In myMeterGroups
                    Where item.RecordType.Trim.Substring(0, 1) = "7" _
                    Order By item.UniversalID _
                    Select item.UniversalID, item.WellName

        MGWells = From item In myMeterGroups _
                      Where item.RecordType.Trim.Substring(0, 1) = "7" _
                      Order By item.UniversalID _
                      Select item.UniversalID, item.WellName

        For Each Item In MGWells

            Debug.Print(Item.ToString)
        Next

...this seems to work, but I'm still not sure that i'm doing this whole process correctly.

Another question is should the Dim MGWells... statement be put somewhere else (form level, class level?) , and does this line actually create the quere or just set it up and then 'MGWells=' line would fill the quere. I have alot of confusion surrounding these statements.

My original idea was to have several presorted queres preloaded and ready to use anywhere in my form class.

[joewmaki]

The Dim MGWells = ... should be all you need.

ERROR MGWells is string and cant be converted to metergroups

In this case you were only returning the UniversalID, not the MeterGroup. If you want to return the entire object drop the Select statement.

Another question is should the Dim MGWells... statement be put somewhere else (form level, class level?) , and does this line actually create the quere or just set it up and then 'MGWells=' line would fill the quere. I have alot of confusion surrounding these statements.

If you need to declare the object outside of the procedure you create it in you can declare it at the Form/Class level something like this:

Dim MGWells as System.Linq.IQueryable(Of String)

Then in your procedure you can just do the

MGWells = ...

[JBourgeois]

Hi rrjii.

Personnaly, I do not use LINQ. The idea behing LINQ is good, but the implementation is awful. You lose more time trying to understand what is happening all the time than you would by writing the equivalent code in a more "standard" way.

I consider the technology to be immature and instable. It forces you to set the compile options in ways that are dangerous. Setting Option Infer On can lead to incidious bugs.

LINQ is still at version 1.0 and will stay that way since Microsoft has decided to put the emphasis on Data entities.

[rrjii2000]

Thanks for the heads up, I did not like using the infered values either. Plus there was way to much happening beind the scenes that I had no control over. It's a neat idea that I could use in many areas, but i've since pulled the plug on LINQ.

[joewmaki]

Hi rrjii.

Personnaly, I do not use LINQ. The idea behing LINQ is good, but the implementation is awful. You lose more time trying to understand what is happening all the time than you would by writing the equivalent code in a more "standard" way.

I consider the technology to be immature and instable. It forces you to set the compile options in ways that are dangerous. Setting Option Infer On can lead to incidious bugs.

LINQ is still at version 1.0 and will stay that way since Microsoft has decided to put the emphasis on Data entities.

I use LINQ occasionally and have never had to use Option Infer. It has it's uses.

[JBourgeois]

Joe.

You are right about not having to set Option Infer On. But most of the code I see does.

There are many reasons for that, the main one is probably that most of the samples around there, even those from Microsoft, do use Option Infer. The second one is probably because many programmers, lazy are we tend to be, would rather have

Dim MyPhotos =

than

Dim MyPhotos As System.Collections.Generic.IEnumerable(Of Photo) =

Declaring a variable with the IEnumerable interface is also a strange thing. Interfaces were created to enable polymorphism. The best use of polymorphism is as a way to create methods that can apply to different types of similar objects.

A variable is not "different types", it is a specific object. So using an interface as the type in a variable declaration is, as far as I am concerned, not something to do except in special situations. In LINQ, it becomes de standard.

And to add to my dislike of LINQ, read the answer to question 2 in the following blog entry from Microsoft: http://msdn.microsoft.com/en-us/data/bb525059.aspx.

LINQ had a very short life, only half a framework version (framework 3.5). It is already seen as being obsolete in the framework 4 where Microsoft suggest that we use the Entity Data Model (EDM) instead. They will still continue to support LINQ, but what they say, basically, is that they LINQ won't evolve from its version 1.0.

This, over all, is the best reason not to count on LINQ.

Another one is that the time you invest in learning to use LINQ properly is time lost in learning to use the basics (ADO.NET) properly.

LINQ is but one element of that race by Microsoft to find a way to program against databases without having to write code. It started with the Data Controls and DataReports in classic VB (neither of those survived the passage to .NET), then the typed DataSets, followed by something whose name I forgot (it had Table in its name), then by LINQ, and now EDM.

The last 4 "program databases fast" technologies appeared one after the other in only 5 versions of the framework. What will it be next. Code written with those 5 years ago is seen as almost obsolete now.

During that same time, the standard ADO.NET that supports all of that has evolved, but the way we wrote code with it 9 years ago is still basically the same, while still leaving you with the full control of what is happening in your application.

ADO.NET code takes a little longer to code, but once you get use to it, it takes a lot less time to debug, and that has lasted for years.

LINQ code takes a little less time to code, but once you get use to it and get to know its intricacies, it ends up being replaced by EDM and you have to start from scratch, again losing a lot of time learning to work properly with it.

And this is without taking into account the loss of performance, that you do not feel while you are developing a project because most of the time the database is still quite small, but that shows up as a problem a few years or even a few months later.

[joewmaki]

Jacques, thanks for the detailed clarification.