Can't get value from DataSet without explicity type casting?

T

Thomas H

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
 
M

Marina

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 said:
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
 
T

Thomas H

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 said:
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 said:
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
 
M

Marina

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 said:
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 said:
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.
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
 
T

Thomas H

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 said:
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 said:
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 said:
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.

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..]
 
M

Marina

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 said:
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 said:
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.
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

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.

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..]
 
T

Thomas H

Great! Thanks again Marina!! I appreciate it!

-Thomas

Marina said:
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 said:
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 said:
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.


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

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.

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..]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top