SPMETAL / LINQ to SharePoint Decimal Types

Question

I've hit a pretty major snag with the entities generated by spmetal / linq to sharepoint. I am hoping someone has dealt with this before.. or maybe I am missing something obvious.

Let's say we have a list with a number field. The field will be expected to hold reasonably precise values.. for example, 0.0000451. Once the value is in the list- SharePoint is fine with it. It displays in the list and display/edit views correctly.

Now if we generate entities based on this list with spmetal, we will get..

//...
private System.Nullable<double> _number;
//..
[Microsoft.SharePoint.Linq.ColumnAttribute(Name="Number", Storage="_number", Required=true, FieldType="Number")]
public System.Nullable<double> Number {
    get {
        return this._number;
    }
    set {
        if ((value != this._number))
        {
            this.OnPropertyChanging("Number", this._number);
            this._number= value;
            this.OnPropertyChanged("Number");
        }
    }
}
//...

Since the type determined by spmetal is doublewe get notation when trying to retrieve it.. for example:

var number = (from x in myDc.MyList select x.Number).First();

number would actually result in a double of 4.51E-05, not 0.0000451.

I am assuming this can be fixed by using a decimal. If I change the types throughout the generated entities to System.Nullable<decimal> I get type conversion failures.

How should I fix this?

EDIT I think maybe it is better to ask "how should I deal with this"? for example, I can simply convert my double values to decimal later on down the line.. my linq query, for example. If I do that, the example case would return the expected result. That seems clunky, though, and I'd like to correct this at the source.

Answer 1

There are several cases like this where SPMetal will give you clunky code. You can, and sometimes have to, fix that. And I admit, it definitely feels better to do it at the source. But there is a downside.

When your data model changes you will have to re-run SPMetal to incorporate your new entities. Any changes you made to the generated file will have to be carefully documented and re-done, or your code will be broken. Therefore, I would advise to leave the generated code alone if you can work with it.

If you can write a wrapper around the objects/methods it would of course be preferable to just converting the types at the end-point, but that's general good programming practice.

Answer 2

4.51E-05 actually equals 0.0000451 so there is nothing wrong with your code.

In other words 4.51E-05 means 4.51 times ten to the minus five power, or 0.0000451