1. Restrict the number columns to an appropriate scale+precision that fits in a .NET decimal. By default, Oracle numbers will allow storing values up to 38 digits total, while a .NET decimal can hold only up to 28. Note, however, that this won't save you if you ever do divisions in your queries. If you just do straight reads/writes this might be enough, though.
   
2. Select the values ROUND()ed appropriately, assuming most troubles stem from having too many decimal places. Quick, extremely ugly and not 100% foolproof either.
   
3. Intercept whatever mechanism tries to read values as decimal and read them as the Oracle data provider-native OracleNumber instead. Then perform some maths to trim the raw data down to a size that fits a .NET decimal before converting it. This has the advantage of failure-proofing your data access without requiring SQL changes, while still providing maximum precision allowed by a decimal. The downside is having to deal with the Oracle specific guts that EF is supposed to hide away from you in the first place. May not actually possible to do with EF in the first place, though... no idea
   

Drastic Actions fucked around with this message at 17:07 on Nov 9, 2016

Dim input As String = InputBox("Input the students grade. Grades shold be between 0 and 100.", "Grade Entry")
If IsNumeric(input) Then
    intScores(intCount) = input
Else
    // handle invalid input
End If

Bognar fucked around with this message at 04:44 on Nov 11, 2016

• VB's static classes are called modules, and they have a single big difference: they are automatically imported into the parent namespace by default. While originally meant to reduce verbosity, particularly when writing small utility modules, In most projects this leads to horrible, horrible namespace pollution, especially since the project system actively encourages the user to import all the namespaces all the time. (Whenever you add a reference in Visual Studio, you can just check a box to automatically import its namespace into every file in your project. Gross.)
  
  Fortunately, the solution is trivial: simply wrap every module in a namespace; I like to name such wrapped modules __ in order to shorten tooltips. In light of that, you could argue that this is actually better than the C# system, since even though the defaut behaviour is very poor you do have a choice whether to auto-import the module or not. (IMO the best system, unsurprisingly, is F#'s where modules are not imported but you can simply add an attribute to make them so).
  
  
• Empty parentheses () when calling a method are optional in VB. This means that the syntax is identical for accessing a field, accessing a parameterless property, and accessing a parameterless member function.
  
  However, VB.net has first-class functions, and those really really don't play well with optional parenthesis: if I write Dim foo = MyClass.MyFunction, is foo the result or a reference to the function itself? 99% of the time it will be the former, but there's no way to distinguish the two if you want to let the user enjoy type inference (and boy does type inference kick rear end). Hence the awkward AddressOf operator, which tells the compiler that you want to treat the following function as a first-class value.
  
  But that's not all. What about lambdas, as in Dim foo = Function(x) x * 2? Well, the VB team seems to have decided that since lambdas definitely didn't exist in Classic VB, they could afford to give them a more C-like design. So there is no AddressOf operator required, but parentheses are required when invoking a lambda.
  
  
• Speaking of lambdas, did you know that you can yield from a lambda in VB.Net, which you cannot do in C#? You do however have to declare the lambda as "iterator", same as you do with regular non-lambda iterator functions:
  

  code:

  dim foo = iterator function()
                yield a
                if poop then exit function
                yield b
                yield c
              end function

  I've never figured out why the "iterator" declaration is required, since the use of "yield" ought to be enough to identify the method as an iterator. I hope Lucian will chime in on this, and I fear the answer may involve the words "option strict off".
  
  
• Every function in VB.Net comes with a complimentary, uninitialised, implicit return variable, with the same name as the function itself. See the "Exit Function" I used in the iterator snippet above? Well, if you use it in a regular, non-iterator function, it will actually return whatever's stored in the return variable. The same will happen if you reach the end of the function without having hit an explicit "Return <whatever>" statement. Quite useful, especially when you're returning a POCO whose properties you gradually set throughot your function.
  
  
• Actually, you can "exit" out of pretty much anything in VB.Net, not just Exit Function / Sub:
  - Exit For / Exit Do / Exit While are like c# break, but if you have nested loops you can break out of the outer one with a single statement - but only if the loops are of different types, which is super weird
  - Exit Select is like the break in a c# switch, but it's not pointless boilerplate, you only need to use it when you actually have code you want to skip
  - Exit Try is perhaps the most interesting, since AFAIK you can't do this one in C# at all
  
  
• This is perhaps my favourite. VB.Net has an interesting legacy keyword called 'Static'. It has nothing to do with C-like static entities (those are called "Shared"). Rather, it can be used to declare a local variable in place of the usual Dim. If you do, the value of the variable is retained between each call of the function where the static variable appears.
  
  In effect, what you have (and what this ultimately compiles to) is a private, thread-safe field that is scoped to a specific method. This is monstrously useful for keeping your classes lean clean, and it's a drat shame that every example of the keyword is some pointless poo poo like:
  
  

  code:

  public function Count as integer
      static countTotal as Integer = 0
      countTotal += 1
      return countTotal
  end function

  when it is far, far more interesting to do stuff like this:
  
  

  code:

  public readonly property Butt as butt
      get
           static hiddenButt as butt = SomeVeryExpensiveFunction
           return hiddenButt
      end get
  end property

  You didn't miss the thread safety, right? Courtesy of an old blog post, here is what that simple "static hiddenButt as butt = SomeVeryExpensiveFunction" line compiles to:
  
  

  code:

  Const STATE_INITIALIZED As Integer = 1
  Const STATE_INITIALIZING As Integer = 2
  Const STATE_UNINITIALIZED As Integer = 0
  
  If $STATIC$get_Butt$0118$hiddenButt$Init.State <> STATE_INITIALIZED Then
      Monitor.Enter($STATIC$DoStuff$0118$hiddenButt$Init)
      Try
          If $STATIC$get_Butt$0118$hiddenButt$Init.State = STATE_UNINITIALIZED Then
              $STATIC$get_Butt$0118$hiddenButt$Init.State = STATE_INITIALIZING
              $STATIC$get_Butt$0118$hiddenButt = SomeVeryExpensiveFunction
              Goto Continue_Code
          End If
          If $STATIC$get_Butt$0118$hiddenButt$Init.State = STATE_INITIALIZING Then
              Throw New IncompleteInitialization()
          End If
      Finally
          $STATIC$get_Butt$0118$hiddenButt$Init.State = STATE_INITIALIZED
          Monitor.Exit($STATIC$get_Butt$0118$hiddenButt$Init)
      End Try
  End If
  Continue_Code:

  So yeah. Pretty nice. And I can't check it right now, but a while ago I took a look myself at the generated MSIL in my project and I seem to remember that 2016 code to have been somewhat more refined compared to the 2003 version I quoted above.