I have a web page that has I'm hooking up a stored procedure on. In this SQL Data Source, I have a parameter that I'm passing back to the SP of type int.
ASP seems to want to default to int32 but the number won't get higher than 6. Is it ok to override the ASP default and put in 16 or will there be a conflict somewhere down the road?
Spec: the DB field has a length of 4 and precision of 10,if that makes a difference in the answer.
Thanks.
If you force it to be for example a byte and the number is over 255 you run the risk of a casting error (and an exception will be thrown). However if you know it not going to be higher than 6 it should not be a problem.
If it was me, I would just use it as a normal int, I am not sure you save much if anything other than a few bytes by making it a byte. The risk of the exception being thrown is too high and you would lose all benefits by making it smaller.
Stick with int32. That's what vb's "Integer" and SQL's INT is, anyway.
You will not gain any significant performance improvement by using a tinyint/byte or an short/int16 instead of int/int32.
In fact, the headaches you might run into in the future caused by all the casting you might have to do for objects that expect int32s will drive you crazy.
When you say the DB field has a length of 4, that means 4 bytes, which is equivalent to an Int32 (4 bytes = 32 bits). That's why your column is being returned as an int32.
There are different integer datatypes in SQL Server -- if you are sure the number won't get higher than 6, you should declare the column in the database as a "tinyint", which uses a single byte and can hold values from 0 to 255. Then the SQL data source should convert it to a "byte" datatype, which will be fine for your purposes.
CLR "byte" == SQL "tinyint" (1 byte) CLR "Short" (or int16) == SQL "smallint" (2 bytes) CLR "int32" == SQL "int"
EDIT: just because you can do something, doesn't mean you should -- I agree with Michael Haren, the development headache of managing these less common datatypes outweighs the small performance gain you would get, unless you are dealing with very high-performance software (in which case, why would you be using ASP.NET?)
You're not saving much if anything by using an Int16 on the ASP side. It still has to load it into a 32-bit register eventually.
Use whatever your Sql Server stored proc has defined. If it's an int in Sql Server, then use Int32 in .NET. smallint in Sql is int16.
Otherwise, Sql Server will just upconvert it automatically, or throw an error if it needs to be downconverted.