Linq and Implicit Conversions


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 10 of 10

Thread: Linq and Implicit Conversions

  1. #1
    Join Date
    Feb 2010
    Location
    Central WV, USA
    Posts
    212

    Linq and Implicit Conversions

    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.'

    Code:
    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?
    Last edited by rrjii2000; 02-24-2011 at 02:47 AM.

  2. #2
    Join Date
    Nov 2003
    Location
    Portland, OR
    Posts
    8,387
    Try adding Option Infer On at the top of the file, or turning it on in the project's properties.
    Phil Weber
    http://www.philweber.com

    Please post questions to the forums, where others may benefit.
    I do not offer free assistance by e-mail. Thank you!

  3. #3
    Join Date
    Feb 2010
    Location
    Central WV, USA
    Posts
    212
    Thanks Phil, that solved my first problem. But now I'm having a hard time making this whole thing work.

    <Collection class>
    Code:
     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>
    Code:
     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>
    Code:
     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
    Last edited by rrjii2000; 02-24-2011 at 02:14 PM.

  4. #4
    Join Date
    Feb 2010
    Location
    Central WV, USA
    Posts
    212
    Code:
     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.
    Last edited by rrjii2000; 02-24-2011 at 04:09 PM.

  5. #5
    Join Date
    May 2004
    Location
    Duluth MN
    Posts
    353
    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 = ...

    ...joe

  6. #6
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    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.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  7. #7
    Join Date
    Feb 2010
    Location
    Central WV, USA
    Posts
    212
    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.

  8. #8
    Join Date
    May 2004
    Location
    Duluth MN
    Posts
    353
    Quote Originally Posted by JBourgeois View Post
    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.

    ...joe

  9. #9
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    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

    Code:
    Dim MyPhotos =
    than

    Code:
    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.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  10. #10
    Join Date
    May 2004
    Location
    Duluth MN
    Posts
    353
    Jacques, thanks for the detailed clarification.

    ...joe

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center