John Saunders said:
What kind of manipulation do you want to do? If you don't know what type
it is at all, if it could be any type at all, then you're quite limited.
In fact, you're limited to the methods of the System.Object type.
The idea is to know what type it is so that the value for a column can be
put in that type and manipulated internally that way. Otherwise, as you say,
one is stuck with System.Object. What is wrong with knowing this in advance
? For instance, a varchar2 column type is usually, I would guess, a
System.String. Some RDBMSs might have column types where one wonders what
actual .NET data type I can use internally. This seems for me to be normal,
to know in advance, for a particular RDBMS and for a particular column type
in that RDBMS, what .NET data type corresponds. I am still baffled that, for
a given RDBMS, I can not get information on how to find this out in some
sort of documentation.
Without this predetermined information one is stuck with writing code which
treats all column data purely as System.Object.
You could go a bit further, and look at the type as returned by
Object.GetType(). There's a world of information in the Type class!
OK, that is fair. But I felt that documentation would tell me this rather
than for me having to set up a table with all the column data types for a
particular RDBMS, and then examine Object.GetType() to find out what .NET
type exists for each column type. But I can do the latter. Still you seem to
be saying that an RDBMS vendor need not publish this information for a
programmer and that it is up to programmers to discover this for themselves.
I find that an odd way at looking at documentation in this case.
Further, you can check to see if it implements IConvertible, in which case
you can try to convert it to various other types.
You can examine it in more detail with the members of the TypeDescriptor
class. In particular, TypeDescriptor.GetConverter.
And finally, you can go more deeply into the type by using Reflection to
find out everything there is to know about the type.
In writing your program, you should ask yourself: if you knew the .NET
type ahead of time, what would you do differently? If it were an int, for
instance.
I would put the value in a variable which was of type 'int' rather than type
System.Object and perhaps manipulate it as such.
Ok, now imagine that the .NET type changes a little. Maybe to a double.
How would you rewrite the code?
Put it in a 'double' rather than an 'int'. Obviously if the column now
supports floating point rather than just whole numbers, the application
probably changes.
Next, imagine that it changes a bit more radically, like to a string. What
changes?
If you continue with this thought experiment, you may be able to focus on
what part of your program is dependant on the data type and what part is
not.
It is not a matter of focus but just a matter of knowing. Have you ever
programmed applications where you had no idea at run-time what data type to
use for a particular value ? Somehow I doubt that, but maybe you have. When
I am dealing with a strongly typed language like C# or C++ I actually want
to know what data types I have. Keeping data with an amorphous
System.Object, and testing its type at run-time in order to manipulate it,
is not my idea of easy programming.