Hey guys, got a question! I've got a DataSet/DataTable, created by using a
DataAdapter.Fill call. I'm writing a C# class that handles all the ADO.NET
work I need, and a different class will call the public methods of this
class.

So; I've created the two public fields I need- Public String _custId and
Public DateTime _orderDate. But, I can't get the values out of the
DataSet/DataTable/DataColumn without doing (in my mind) useless casting! For
instance, this doesn't work:

_custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];

I get the message "Cannot implicitly convert type 'object' to 'string' ". To
make it work, I have to do:

_custID = (String)dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
....or....
_custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();

I'm confused as to why? The following line displays "System.String":

Console.WriteLine(dsOrders.Tables["tblOrd"].Rows[iCurrentRow].Table.Columns[
0].DataType);

So, shouldn't that mean that I don't have to do anything else? Why do I need
to use (String) or .ToString() ?

And I also can't get the DateTime into a variable. Trying

_orderDate = dsHousing.Tables["tblOrd"].Rows[iCurrentRow][1];

gives me "Cannot implicitly convert type 'object' to 'System.DateTime' ".
And, again, if I display the value for Columns[1].DataType, it shows me
"System.DateTime". Worse, there's no ".ToDateTime()" method of the Column
object, so the only way I can get the DateTime field out is to cast it to a
string, and then convert it back to a DateTime. Compared to my problem with
the String column, I'm doing twice the un-necessary work just to get the
DateTime column!

Is this really what's supposed to happen? If the DataType shows string, why
do I need to perform an explicit conversion from object to string? It seems
like I'm doing un-necessary work; if the value is stored as a certain
datatype, I should be able to pull it out of the DataTable and put it into a
variable of the same type.

I even toyed with the idea of .NET assuming I wanted the DataColumn being
put into a String- but I can't find a property of DataColumn that just gives
me the value. In classic ADO, there was a Field object, which had a Value
property. I can understand "DataColumn" being an object, but is there a
specific property for pulling the value out of DataColumn? For instance, if
those code samples I just gave would be in classic ADO, I would be trying to
say _CustID = rs.Fields(x).Value.

Oh I'm using VS 2003.NET EA, with WinXP, .NET 1.1, and have "Using
System.Data" and "Using System.Data.OracleClient" at the top of my C# class
definition. At first I thought this might be Oracle related, but
DataSet/DataTable/DataColumn is part of the System.Data namespace.

Thanks!

-Thomas

Re: Can't get value from DataSet without explicity type casting? by Marina

Marina
Fri Jul 23 10:08:48 CDT 2004

Each column has a datatype. This is good, since you want your value stored
in its native format.

However, the datarow's Item property has to be generic enough to be able to
return to you any type of object. If it's a string, it will return a
string. If it's an int, it will return an int.

So the most it knows, is that it will return an object - can't be any more
specific then that. So the Item property returns an object - that is what
you get.

Now, in reality, that object can be an integer, a string, a date, etc. But
the compiler doesn't know what it's going to be at compile time. So you
have to cast it to whatever type it really is, to use it.

"Thomas H" <T@H> wrote in message
news:eF9r$XMcEHA.644@tk2msftngp13.phx.gbl...
> Hey guys, got a question! I've got a DataSet/DataTable, created by using a
> DataAdapter.Fill call. I'm writing a C# class that handles all the ADO.NET
> work I need, and a different class will call the public methods of this
> class.
>
> So; I've created the two public fields I need- Public String _custId and
> Public DateTime _orderDate. But, I can't get the values out of the
> DataSet/DataTable/DataColumn without doing (in my mind) useless casting!
For
> instance, this doesn't work:
>
> _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
>
> I get the message "Cannot implicitly convert type 'object' to 'string' ".
To
> make it work, I have to do:
>
> _custID = (String)dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> ....or....
> _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();
>
> I'm confused as to why? The following line displays "System.String":
>
>
Console.WriteLine(dsOrders.Tables["tblOrd"].Rows[iCurrentRow].Table.Columns[
> 0].DataType);
>
> So, shouldn't that mean that I don't have to do anything else? Why do I
need
> to use (String) or .ToString() ?
>
> And I also can't get the DateTime into a variable. Trying
>
> _orderDate = dsHousing.Tables["tblOrd"].Rows[iCurrentRow][1];
>
> gives me "Cannot implicitly convert type 'object' to 'System.DateTime' ".
> And, again, if I display the value for Columns[1].DataType, it shows me
> "System.DateTime". Worse, there's no ".ToDateTime()" method of the Column
> object, so the only way I can get the DateTime field out is to cast it to
a
> string, and then convert it back to a DateTime. Compared to my problem
with
> the String column, I'm doing twice the un-necessary work just to get the
> DateTime column!
>
> Is this really what's supposed to happen? If the DataType shows string,
why
> do I need to perform an explicit conversion from object to string? It
seems
> like I'm doing un-necessary work; if the value is stored as a certain
> datatype, I should be able to pull it out of the DataTable and put it into
a
> variable of the same type.
>
> I even toyed with the idea of .NET assuming I wanted the DataColumn being
> put into a String- but I can't find a property of DataColumn that just
gives
> me the value. In classic ADO, there was a Field object, which had a Value
> property. I can understand "DataColumn" being an object, but is there a
> specific property for pulling the value out of DataColumn? For instance,
if
> those code samples I just gave would be in classic ADO, I would be trying
to
> say _CustID = rs.Fields(x).Value.
>
> Oh I'm using VS 2003.NET EA, with WinXP, .NET 1.1, and have "Using
> System.Data" and "Using System.Data.OracleClient" at the top of my C#
class
> definition. At first I thought this might be Oracle related, but
> DataSet/DataTable/DataColumn is part of the System.Data namespace.
>
> Thanks!
>
> -Thomas
>
>



Re: Can't get value from DataSet without explicity type casting? by Thomas

Thomas
Fri Jul 23 11:04:49 CDT 2004

Marina, thanks for the explanation! I never thought about compile time!
Now it makes sense for all the casting- even though it still seems like a
runaround for (DateTime)(String)DateTimeColumn. If I created a strongly
typed dataset, based on an XSD file, would the compiler still require
casting? Will the XSD be built along with the assembly, and "lock" my
column into one single datatype- and then I could avoid casting?

Oh, and you mentioned the datarow's Item property- is there a reason why
there's now DataColumn.Item? I could say datarow.itemarray[1], but it
points back to a column. I would've expected a datarow.itemarray[1].Item to
be available! Is there a property of the DataColumn that returns the actual
value? Or is DataColumn "itself" the whole object, including the value, and
there's no property for a value?

Thanks for clearing this up; I can't believe the amount of time I fought
with this. I guess classic ADO didn't have enough checking built into it,
and that's why it allowed me to use Field.Value without conversions?

Thanks again!!

-Thomas

"Marina" <someone@nospam.com> wrote in message
news:eH3C2bMcEHA.1152@TK2MSFTNGP09.phx.gbl...
> Each column has a datatype. This is good, since you want your value
stored
> in its native format.
>
> However, the datarow's Item property has to be generic enough to be able
to
> return to you any type of object. If it's a string, it will return a
> string. If it's an int, it will return an int.
>
> So the most it knows, is that it will return an object - can't be any more
> specific then that. So the Item property returns an object - that is what
> you get.
>
> Now, in reality, that object can be an integer, a string, a date, etc.
But
> the compiler doesn't know what it's going to be at compile time. So you
> have to cast it to whatever type it really is, to use it.
>
> "Thomas H" <T@H> wrote in message
> news:eF9r$XMcEHA.644@tk2msftngp13.phx.gbl...
> > Hey guys, got a question! I've got a DataSet/DataTable, created by using
a
> > DataAdapter.Fill call. I'm writing a C# class that handles all the
ADO.NET
> > work I need, and a different class will call the public methods of this
> > class.
> >
> > So; I've created the two public fields I need- Public String _custId and
> > Public DateTime _orderDate. But, I can't get the values out of the
> > DataSet/DataTable/DataColumn without doing (in my mind) useless casting!
> For
> > instance, this doesn't work:
> >
> > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> >
> > I get the message "Cannot implicitly convert type 'object' to 'string'
".
> To
> > make it work, I have to do:
> >
> > _custID = (String)dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> > ....or....
> > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();
> >
> > I'm confused as to why? The following line displays "System.String":
> >
> >
>
Console.WriteLine(dsOrders.Tables["tblOrd"].Rows[iCurrentRow].Table.Columns[
> > 0].DataType);
> >
> > So, shouldn't that mean that I don't have to do anything else? Why do I
> need
> > to use (String) or .ToString() ?
> >
> > And I also can't get the DateTime into a variable. Trying
> >
> > _orderDate = dsHousing.Tables["tblOrd"].Rows[iCurrentRow][1];
> >
> > gives me "Cannot implicitly convert type 'object' to 'System.DateTime'
".
> > And, again, if I display the value for Columns[1].DataType, it shows me
> > "System.DateTime". Worse, there's no ".ToDateTime()" method of the
Column
> > object, so the only way I can get the DateTime field out is to cast it
to
> a
> > string, and then convert it back to a DateTime. Compared to my problem
> with
> > the String column, I'm doing twice the un-necessary work just to get the
> > DateTime column!
> >
> > Is this really what's supposed to happen? If the DataType shows string,
> why
> > do I need to perform an explicit conversion from object to string? It
> seems
> > like I'm doing un-necessary work; if the value is stored as a certain
> > datatype, I should be able to pull it out of the DataTable and put it
into
> a
> > variable of the same type.
> >
> > I even toyed with the idea of .NET assuming I wanted the DataColumn
being
> > put into a String- but I can't find a property of DataColumn that just
> gives
> > me the value. In classic ADO, there was a Field object, which had a
Value
> > property. I can understand "DataColumn" being an object, but is there a
> > specific property for pulling the value out of DataColumn? For instance,
> if
> > those code samples I just gave would be in classic ADO, I would be
trying
> to
> > say _CustID = rs.Fields(x).Value.
> >
> > Oh I'm using VS 2003.NET EA, with WinXP, .NET 1.1, and have "Using
> > System.Data" and "Using System.Data.OracleClient" at the top of my C#
> class
> > definition. At first I thought this might be Oracle related, but
> > DataSet/DataTable/DataColumn is part of the System.Data namespace.
> >
> > Thanks!
> >
> > -Thomas
> >
> >
>
>



Re: Can't get value from DataSet without explicity type casting? by Marina

Marina
Fri Jul 23 11:15:11 CDT 2004

The DataColumn is just a definition for the column. It does not hold
values - that is in the datarows. Otherwise, for which row would the
datacolumn give u the value?

The ItemArray property in the datarow object, is just there to give u all
the items in that datarow in one array. But this property returns an
Array - so you just index into it by numeric index.

As for typed datasets, those are around just for the purpose of having a
strongly typed data source with compile time checking for types, etc.

Personally, I have found them to not be useful in generic kind of
situations,they are a pain to keep up to date when your database schema
changes, etc. But I know a lot of people really like them, so it's up to
you if you find it useful.


"Thomas H" <T@H> wrote in message
news:uI8GK7McEHA.3988@tk2msftngp13.phx.gbl...
> Marina, thanks for the explanation! I never thought about compile time!
> Now it makes sense for all the casting- even though it still seems like a
> runaround for (DateTime)(String)DateTimeColumn. If I created a strongly
> typed dataset, based on an XSD file, would the compiler still require
> casting? Will the XSD be built along with the assembly, and "lock" my
> column into one single datatype- and then I could avoid casting?
>
> Oh, and you mentioned the datarow's Item property- is there a reason why
> there's now DataColumn.Item? I could say datarow.itemarray[1], but it
> points back to a column. I would've expected a datarow.itemarray[1].Item
to
> be available! Is there a property of the DataColumn that returns the
actual
> value? Or is DataColumn "itself" the whole object, including the value,
and
> there's no property for a value?
>
> Thanks for clearing this up; I can't believe the amount of time I fought
> with this. I guess classic ADO didn't have enough checking built into it,
> and that's why it allowed me to use Field.Value without conversions?
>
> Thanks again!!
>
> -Thomas
>
> "Marina" <someone@nospam.com> wrote in message
> news:eH3C2bMcEHA.1152@TK2MSFTNGP09.phx.gbl...
> > Each column has a datatype. This is good, since you want your value
> stored
> > in its native format.
> >
> > However, the datarow's Item property has to be generic enough to be able
> to
> > return to you any type of object. If it's a string, it will return a
> > string. If it's an int, it will return an int.
> >
> > So the most it knows, is that it will return an object - can't be any
more
> > specific then that. So the Item property returns an object - that is
what
> > you get.
> >
> > Now, in reality, that object can be an integer, a string, a date, etc.
> But
> > the compiler doesn't know what it's going to be at compile time. So you
> > have to cast it to whatever type it really is, to use it.
> >
> > "Thomas H" <T@H> wrote in message
> > news:eF9r$XMcEHA.644@tk2msftngp13.phx.gbl...
> > > Hey guys, got a question! I've got a DataSet/DataTable, created by
using
> a
> > > DataAdapter.Fill call. I'm writing a C# class that handles all the
> ADO.NET
> > > work I need, and a different class will call the public methods of
this
> > > class.
> > >
> > > So; I've created the two public fields I need- Public String _custId
and
> > > Public DateTime _orderDate. But, I can't get the values out of the
> > > DataSet/DataTable/DataColumn without doing (in my mind) useless
casting!
> > For
> > > instance, this doesn't work:
> > >
> > > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> > >
> > > I get the message "Cannot implicitly convert type 'object' to 'string'
> ".
> > To
> > > make it work, I have to do:
> > >
> > > _custID = (String)dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> > > ....or....
> > > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();
> > >
> > > I'm confused as to why? The following line displays "System.String":
> > >
> > >
> >
>
Console.WriteLine(dsOrders.Tables["tblOrd"].Rows[iCurrentRow].Table.Columns[
> > > 0].DataType);
> > >
> > > So, shouldn't that mean that I don't have to do anything else? Why do
I
> > need
> > > to use (String) or .ToString() ?
> > >
> > > And I also can't get the DateTime into a variable. Trying
> > >
> > > _orderDate = dsHousing.Tables["tblOrd"].Rows[iCurrentRow][1];
> > >
> > > gives me "Cannot implicitly convert type 'object' to 'System.DateTime'
> ".
> > > And, again, if I display the value for Columns[1].DataType, it shows
me
> > > "System.DateTime". Worse, there's no ".ToDateTime()" method of the
> Column
> > > object, so the only way I can get the DateTime field out is to cast it
> to
> > a
> > > string, and then convert it back to a DateTime. Compared to my problem
> > with
> > > the String column, I'm doing twice the un-necessary work just to get
the
> > > DateTime column!
> > >
> > > Is this really what's supposed to happen? If the DataType shows
string,
> > why
> > > do I need to perform an explicit conversion from object to string? It
> > seems
> > > like I'm doing un-necessary work; if the value is stored as a certain
> > > datatype, I should be able to pull it out of the DataTable and put it
> into
> > a
> > > variable of the same type.
> > >
> > > I even toyed with the idea of .NET assuming I wanted the DataColumn
> being
> > > put into a String- but I can't find a property of DataColumn that just
> > gives
> > > me the value. In classic ADO, there was a Field object, which had a
> Value
> > > property. I can understand "DataColumn" being an object, but is there
a
> > > specific property for pulling the value out of DataColumn? For
instance,
> > if
> > > those code samples I just gave would be in classic ADO, I would be
> trying
> > to
> > > say _CustID = rs.Fields(x).Value.
> > >
> > > Oh I'm using VS 2003.NET EA, with WinXP, .NET 1.1, and have "Using
> > > System.Data" and "Using System.Data.OracleClient" at the top of my C#
> > class
> > > definition. At first I thought this might be Oracle related, but
> > > DataSet/DataTable/DataColumn is part of the System.Data namespace.
> > >
> > > Thanks!
> > >
> > > -Thomas
> > >
> > >
> >
> >
>
>



Re: Can't get value from DataSet without explicity type casting? by Thomas

Thomas
Fri Jul 23 12:30:15 CDT 2004

Okay, so that's why DataColumn only exists under DataTable, and not under
DataRow! Got it! I was thinking that I should be able to get a
DataSet.DataTable.DataRow.DataColumn reference. Does it make a difference
if I use either of the following?

_custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();
or
_custID =
dsOrders.Tables["tblOrd"].Rows[iCurrentRow].ItemArray[1].ToString();

Are they both the same, and the first one is just a shortcut for the second?
Or is that what you meant for ItemArray; it's meant for returning an array,
and not for returning just one location?

And that's great- that's exactly why I chose a weakly typed DS. A strongly
typed DS didn't make sense for this particular application; it seemed like
overkill, without much benefit. Glad to hear that I'm not alone with that
opinion!

Thanks again for your help!

-Thomas

"Marina" <someone@nospam.com> wrote in message
news:OraA8ANcEHA.3864@TK2MSFTNGP10.phx.gbl...
> The DataColumn is just a definition for the column. It does not hold
> values - that is in the datarows. Otherwise, for which row would the
> datacolumn give u the value?
>
> The ItemArray property in the datarow object, is just there to give u all
> the items in that datarow in one array. But this property returns an
> Array - so you just index into it by numeric index.
>
> As for typed datasets, those are around just for the purpose of having a
> strongly typed data source with compile time checking for types, etc.
>
> Personally, I have found them to not be useful in generic kind of
> situations,they are a pain to keep up to date when your database schema
> changes, etc. But I know a lot of people really like them, so it's up to
> you if you find it useful.
>
>
> "Thomas H" <T@H> wrote in message
> news:uI8GK7McEHA.3988@tk2msftngp13.phx.gbl...
> > Marina, thanks for the explanation! I never thought about compile time!
> > Now it makes sense for all the casting- even though it still seems like
a
> > runaround for (DateTime)(String)DateTimeColumn. If I created a strongly
> > typed dataset, based on an XSD file, would the compiler still require
> > casting? Will the XSD be built along with the assembly, and "lock" my
> > column into one single datatype- and then I could avoid casting?
> >
> > Oh, and you mentioned the datarow's Item property- is there a reason why
> > there's now DataColumn.Item? I could say datarow.itemarray[1], but it
> > points back to a column. I would've expected a
datarow.itemarray[1].Item
> > to be available! Is there a property of the DataColumn that returns the
> > actual value? Or is DataColumn "itself" the whole object, including the
> > value, and there's no property for a value?
> >
> > Thanks for clearing this up; I can't believe the amount of time I fought
> > with this. I guess classic ADO didn't have enough checking built into
it,
> > and that's why it allowed me to use Field.Value without conversions?
> >
> > Thanks again!!
> >
> > -Thomas
> >
> > "Marina" <someone@nospam.com> wrote in message
> > news:eH3C2bMcEHA.1152@TK2MSFTNGP09.phx.gbl...
> > > Each column has a datatype. This is good, since you want your value
> > stored
> > > in its native format.
> > >
> > > However, the datarow's Item property has to be generic enough to be
able
> > to
> > > return to you any type of object. If it's a string, it will return a
> > > string. If it's an int, it will return an int.
> > >
> > > So the most it knows, is that it will return an object - can't be any
> more
> > > specific then that. So the Item property returns an object - that is
> what
> > > you get.
> > >
> > > Now, in reality, that object can be an integer, a string, a date, etc.
> > But
> > > the compiler doesn't know what it's going to be at compile time. So
you
> > > have to cast it to whatever type it really is, to use it.
> > >
> > > "Thomas H" <T@H> wrote in message
> > > news:eF9r$XMcEHA.644@tk2msftngp13.phx.gbl...
> > > > Hey guys, got a question! I've got a DataSet/DataTable, created by
> using
> > a
> > > > DataAdapter.Fill call. I'm writing a C# class that handles all the
> > ADO.NET
> > > > work I need, and a different class will call the public methods of
> this
> > > > class.
> > > >
> > > > So; I've created the two public fields I need- Public String _custId
> and
> > > > Public DateTime _orderDate. But, I can't get the values out of the
> > > > DataSet/DataTable/DataColumn without doing (in my mind) useless
> casting!
> > > For
> > > > instance, this doesn't work:
> > > >
> > > > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> > > >
> > > > I get the message "Cannot implicitly convert type 'object' to
'string'
> > > > [..snip..]



Re: Can't get value from DataSet without explicity type casting? by Marina

Marina
Fri Jul 23 14:03:06 CDT 2004

They are not the same in that in the first case you are pulling at index 0,
and in the second case at index 1. But if you used the same index it would
be the same thing.

I don't see any reason to go through the itemarray, so I would use the
indexer directly. Also, using that indexer you can index by column name, not
just numeric index, which is very convenient.


"Thomas H" <T@H> wrote in message
news:Oo437qNcEHA.3512@TK2MSFTNGP12.phx.gbl...
> Okay, so that's why DataColumn only exists under DataTable, and not under
> DataRow! Got it! I was thinking that I should be able to get a
> DataSet.DataTable.DataRow.DataColumn reference. Does it make a difference
> if I use either of the following?
>
> _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();
> or
> _custID =
> dsOrders.Tables["tblOrd"].Rows[iCurrentRow].ItemArray[1].ToString();
>
> Are they both the same, and the first one is just a shortcut for the
second?
> Or is that what you meant for ItemArray; it's meant for returning an
array,
> and not for returning just one location?
>
> And that's great- that's exactly why I chose a weakly typed DS. A
strongly
> typed DS didn't make sense for this particular application; it seemed like
> overkill, without much benefit. Glad to hear that I'm not alone with that
> opinion!
>
> Thanks again for your help!
>
> -Thomas
>
> "Marina" <someone@nospam.com> wrote in message
> news:OraA8ANcEHA.3864@TK2MSFTNGP10.phx.gbl...
> > The DataColumn is just a definition for the column. It does not hold
> > values - that is in the datarows. Otherwise, for which row would the
> > datacolumn give u the value?
> >
> > The ItemArray property in the datarow object, is just there to give u
all
> > the items in that datarow in one array. But this property returns an
> > Array - so you just index into it by numeric index.
> >
> > As for typed datasets, those are around just for the purpose of having a
> > strongly typed data source with compile time checking for types, etc.
> >
> > Personally, I have found them to not be useful in generic kind of
> > situations,they are a pain to keep up to date when your database schema
> > changes, etc. But I know a lot of people really like them, so it's up
to
> > you if you find it useful.
> >
> >
> > "Thomas H" <T@H> wrote in message
> > news:uI8GK7McEHA.3988@tk2msftngp13.phx.gbl...
> > > Marina, thanks for the explanation! I never thought about compile
time!
> > > Now it makes sense for all the casting- even though it still seems
like
> a
> > > runaround for (DateTime)(String)DateTimeColumn. If I created a
strongly
> > > typed dataset, based on an XSD file, would the compiler still require
> > > casting? Will the XSD be built along with the assembly, and "lock" my
> > > column into one single datatype- and then I could avoid casting?
> > >
> > > Oh, and you mentioned the datarow's Item property- is there a reason
why
> > > there's now DataColumn.Item? I could say datarow.itemarray[1], but it
> > > points back to a column. I would've expected a
> datarow.itemarray[1].Item
> > > to be available! Is there a property of the DataColumn that returns
the
> > > actual value? Or is DataColumn "itself" the whole object, including
the
> > > value, and there's no property for a value?
> > >
> > > Thanks for clearing this up; I can't believe the amount of time I
fought
> > > with this. I guess classic ADO didn't have enough checking built into
> it,
> > > and that's why it allowed me to use Field.Value without conversions?
> > >
> > > Thanks again!!
> > >
> > > -Thomas
> > >
> > > "Marina" <someone@nospam.com> wrote in message
> > > news:eH3C2bMcEHA.1152@TK2MSFTNGP09.phx.gbl...
> > > > Each column has a datatype. This is good, since you want your value
> > > stored
> > > > in its native format.
> > > >
> > > > However, the datarow's Item property has to be generic enough to be
> able
> > > to
> > > > return to you any type of object. If it's a string, it will return
a
> > > > string. If it's an int, it will return an int.
> > > >
> > > > So the most it knows, is that it will return an object - can't be
any
> > more
> > > > specific then that. So the Item property returns an object - that is
> > what
> > > > you get.
> > > >
> > > > Now, in reality, that object can be an integer, a string, a date,
etc.
> > > But
> > > > the compiler doesn't know what it's going to be at compile time. So
> you
> > > > have to cast it to whatever type it really is, to use it.
> > > >
> > > > "Thomas H" <T@H> wrote in message
> > > > news:eF9r$XMcEHA.644@tk2msftngp13.phx.gbl...
> > > > > Hey guys, got a question! I've got a DataSet/DataTable, created by
> > using
> > > a
> > > > > DataAdapter.Fill call. I'm writing a C# class that handles all the
> > > ADO.NET
> > > > > work I need, and a different class will call the public methods of
> > this
> > > > > class.
> > > > >
> > > > > So; I've created the two public fields I need- Public String
_custId
> > and
> > > > > Public DateTime _orderDate. But, I can't get the values out of the
> > > > > DataSet/DataTable/DataColumn without doing (in my mind) useless
> > casting!
> > > > For
> > > > > instance, this doesn't work:
> > > > >
> > > > > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> > > > >
> > > > > I get the message "Cannot implicitly convert type 'object' to
> 'string'
> > > > > [..snip..]
>
>



Re: Can't get value from DataSet without explicity type casting? by Thomas

Thomas
Fri Jul 23 14:24:29 CDT 2004

Great! Thanks again Marina!! I appreciate it!

-Thomas

"Marina" <someone@nospam.com> wrote in message
news:uF%23GxeOcEHA.712@TK2MSFTNGP11.phx.gbl...
> They are not the same in that in the first case you are pulling at index
0,
> and in the second case at index 1. But if you used the same index it
would
> be the same thing.
>
> I don't see any reason to go through the itemarray, so I would use the
> indexer directly. Also, using that indexer you can index by column name,
not
> just numeric index, which is very convenient.
>
>
> "Thomas H" <T@H> wrote in message
> news:Oo437qNcEHA.3512@TK2MSFTNGP12.phx.gbl...
> > Okay, so that's why DataColumn only exists under DataTable, and not
under
> > DataRow! Got it! I was thinking that I should be able to get a
> > DataSet.DataTable.DataRow.DataColumn reference. Does it make a
difference
> > if I use either of the following?
> >
> > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0].ToString();
> > or
> > _custID =
> > dsOrders.Tables["tblOrd"].Rows[iCurrentRow].ItemArray[1].ToString();
> >
> > Are they both the same, and the first one is just a shortcut for the
> second?
> > Or is that what you meant for ItemArray; it's meant for returning an
> array,
> > and not for returning just one location?
> >
> > And that's great- that's exactly why I chose a weakly typed DS. A
> strongly
> > typed DS didn't make sense for this particular application; it seemed
like
> > overkill, without much benefit. Glad to hear that I'm not alone with
that
> > opinion!
> >
> > Thanks again for your help!
> >
> > -Thomas
> >
> > "Marina" <someone@nospam.com> wrote in message
> > news:OraA8ANcEHA.3864@TK2MSFTNGP10.phx.gbl...
> > > The DataColumn is just a definition for the column. It does not hold
> > > values - that is in the datarows. Otherwise, for which row would the
> > > datacolumn give u the value?
> > >
> > > The ItemArray property in the datarow object, is just there to give u
> all
> > > the items in that datarow in one array. But this property returns an
> > > Array - so you just index into it by numeric index.
> > >
> > > As for typed datasets, those are around just for the purpose of having
a
> > > strongly typed data source with compile time checking for types, etc.
> > >
> > > Personally, I have found them to not be useful in generic kind of
> > > situations,they are a pain to keep up to date when your database
schema
> > > changes, etc. But I know a lot of people really like them, so it's up
> to
> > > you if you find it useful.
> > >
> > >
> > > "Thomas H" <T@H> wrote in message
> > > news:uI8GK7McEHA.3988@tk2msftngp13.phx.gbl...
> > > > Marina, thanks for the explanation! I never thought about compile
> time!
> > > > Now it makes sense for all the casting- even though it still seems
> like
> > a
> > > > runaround for (DateTime)(String)DateTimeColumn. If I created a
> strongly
> > > > typed dataset, based on an XSD file, would the compiler still
require
> > > > casting? Will the XSD be built along with the assembly, and "lock"
my
> > > > column into one single datatype- and then I could avoid casting?
> > > >
> > > > Oh, and you mentioned the datarow's Item property- is there a reason
> why
> > > > there's now DataColumn.Item? I could say datarow.itemarray[1], but
it
> > > > points back to a column. I would've expected a
> > datarow.itemarray[1].Item
> > > > to be available! Is there a property of the DataColumn that returns
> the
> > > > actual value? Or is DataColumn "itself" the whole object, including
> the
> > > > value, and there's no property for a value?
> > > >
> > > > Thanks for clearing this up; I can't believe the amount of time I
> fought
> > > > with this. I guess classic ADO didn't have enough checking built
into
> > it,
> > > > and that's why it allowed me to use Field.Value without conversions?
> > > >
> > > > Thanks again!!
> > > >
> > > > -Thomas
> > > >
> > > > "Marina" <someone@nospam.com> wrote in message
> > > > news:eH3C2bMcEHA.1152@TK2MSFTNGP09.phx.gbl...
> > > > > Each column has a datatype. This is good, since you want your
value
> > > > stored
> > > > > in its native format.
> > > > >
> > > > > However, the datarow's Item property has to be generic enough to
be
> > able
> > > > to
> > > > > return to you any type of object. If it's a string, it will
return
> a
> > > > > string. If it's an int, it will return an int.
> > > > >
> > > > > So the most it knows, is that it will return an object - can't be
> any
> > > more
> > > > > specific then that. So the Item property returns an object - that
is
> > > what
> > > > > you get.
> > > > >
> > > > > Now, in reality, that object can be an integer, a string, a date,
> etc.
> > > > But
> > > > > the compiler doesn't know what it's going to be at compile time.
So
> > you
> > > > > have to cast it to whatever type it really is, to use it.
> > > > >
> > > > > "Thomas H" <T@H> wrote in message
> > > > > news:eF9r$XMcEHA.644@tk2msftngp13.phx.gbl...
> > > > > > Hey guys, got a question! I've got a DataSet/DataTable, created
by
> > > using
> > > > a
> > > > > > DataAdapter.Fill call. I'm writing a C# class that handles all
the
> > > > ADO.NET
> > > > > > work I need, and a different class will call the public methods
of
> > > this
> > > > > > class.
> > > > > >
> > > > > > So; I've created the two public fields I need- Public String
> _custId
> > > and
> > > > > > Public DateTime _orderDate. But, I can't get the values out of
the
> > > > > > DataSet/DataTable/DataColumn without doing (in my mind) useless
> > > casting!
> > > > > For
> > > > > > instance, this doesn't work:
> > > > > >
> > > > > > _custID = dsOrders.Tables["tblOrd"].Rows[iCurrentRow][0];
> > > > > >
> > > > > > I get the message "Cannot implicitly convert type 'object' to
> > 'string'
> > > > > > [..snip..]
> >
> >
>
>