...
Thank you Bjorn for your explanation.
You're welcome.
And select returns sql int data type,
which is the same as Int32 in C#.
Okej, so you should use GetInt32 as that *is* what you're reading from the
db...
But number is always small, from 0 to 23, so why use
Int32 dataType and use additional memory?
Because you can't change the datatype of what you're reading... ;-)
Well, actually I'd guess that you possibly *could* do that in some way, if
you encapsulate the reading in a stored procedure in the db, which in turn
"casts" it somehow to a short instead of an int, but my guess is that it
would be overkill...
Because of that, I use Int16 dataType:
Int16 hourS;
hourS=Convert.Toint16(rdr.getInt32(1));
It works.
This should probably also work:
Int16 hours = (Int16) rdr.getInt32(1);
or
short hours = (short) rdr.getInt32(1);
But it brings a lot of work.
Not explicitly that, but other things might...
Everywhere in code where I use Int16 variables I must
write (Int16) in front of line, for example:
hours=(Int16)(hourS+1);
If i work with Int32 variables, no additional coding is needed:
Int32 hourS;
hourS=hourS+1;
and also no call to conversion function is needed (so, less processor
work):
hourS=rdr.getInt32(1);
Yes and No.
If hourS is declared as an Int16, hourS is *always* an Int16, no matter how
you assigned the value to it. However, the problem *there* lies in what type
a *literal* is of...
In your code:
hourS = hourS + 1;
....whether or not hourS is of type short (Int16), you also have the literal
1, which default is of type int (Int32)! Therefore, you *still* need to cast
the expression if you use short variables.
So these are the reasons to use Int32 DataType.
You suggest short?
As I said before, Int16 and "short" are interchangable in your code, as
short simply is an alias for Int16.
Personally, I prefer short before Int16, because I switch a lot between C#,
C++ and Java. It makes a lot of things easier for me...
In this specific case, I would suggest you use int instead of Int32.
That's the only way you can eliminate the casts of such expressions as
mentioned above...
If you think that it would make your program "too big" because of excessive
use of memory, then you're stuck with the casting, when you use such
literals in the expressions...
// Bjorn A