I'm learning how to use Microsoft's relatively new data interface called
LINQ, which is designed to allow developers to treat different data types (like XML files, and databases) and data queries (such as SQL queries) as objects. This in theory allows the developer to be able to debug data queries at compile time have better knowledge of what is happening during runtime.
The problem is that Microsoft forgot that a lot of web application development uses its SQL Server db as a backend. Now, SQL Server is a mature product and the basic data types that it incorporates have not changed for a significant time.
The problem I've been happening deals with integers:
- tinyint (8-bit) - 0 - 255
- smallint (16-bit) -2^15 (-32,768) to 2^15-1 (32,767)
- int (32-bit) - -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647)
I use the tinyint for lookup tables where there will be a very limited number of items. In this case, it was a table for status, which currently has two items,
active and
inactive.
Now, for LINQ, you can manually define your tables as a class. So, my status table looked like this:
[Table(Name = "Status")] public class t_Status { [Column(IsPrimaryKey = true)] public int statusID; [Column] public string type; private EntitySet _staLU; [Association(Storage = "_staLU", OtherKey = "statusID")] public EntitySet StatLU { get { return this._staLU; } set { this._staLU.Assign(value); } }}So when I try to use this I get a "specified cast is not valid". After some searching on Google, I find that LINQ doesnt automatically convert between the various int types. I can understand this from a big to small perspective - you would not want to lose digits/accuracy. But for small to big? It should be able to automatically figure that out in the background.
Further annoyance was found when I discovered I can't even easily assign the tinyint as a proper type in C# - I can with smallint by using
public int16 statusID; but that means effectively I have to use a less efficient (memory wise), larger type in my database to be able to use LINQ.
It seems to me that Microsoft should have thought this through - DBAs are not going to be happy having to redesign databases to accomodate this miss.