H
H5N1
Hi there
I know that a problem of different datetime strings formatting between
asp.net and ms sql has been covered here widely, but what I couldn't
find is the 100% safe way of getting datetime values from ms sql,
processing them in asp.net and getting them back into sql without any
risk with inconsistent Culture settings etc.
My question is: wouldn't keeping the datetime variables all the time in
datetime type, without any String conversions, prevent all such
problems?
I was trying to check it but there are few obstacles when sticking to
declarative databinding:
1) session parameters
Let's say I'm keeping datetime variable in a session. Then, I want to
use it as a parameter in a datasource. But the variable in session will
be boxed to Object type, and I have no control on how datasource will
cast it - how can I prevent it from casting it to string and inserting
it into the query as a culture-unsafe string?
I think Select Parameters collection in Data Source properties might
help - after choosing session parameter I can show Advanced Properties
and change it's type (from string to datetime) - will Data Source use
this information to cast the session variable onto datetime properly?
2) dropdownlist values
I want to bind some datetime values to dropdownlist and use its
selected value as a control parameter of a data source. Does it mean,
that implicit toString conversion must happen during binding to ddl?
ddl.selectedValue has String type - does it mean, that everything bound
to ddl is converted to string - no way to prevent it? If it's true,
then how would it be done in case of datetime, which may be casted to
string in many different ways (because of formatting possibilities)?
Would standard datetime.toString() be used when populating ddl?
thanks a lot for any insight
cheers
HP
I know that a problem of different datetime strings formatting between
asp.net and ms sql has been covered here widely, but what I couldn't
find is the 100% safe way of getting datetime values from ms sql,
processing them in asp.net and getting them back into sql without any
risk with inconsistent Culture settings etc.
My question is: wouldn't keeping the datetime variables all the time in
datetime type, without any String conversions, prevent all such
problems?
I was trying to check it but there are few obstacles when sticking to
declarative databinding:
1) session parameters
Let's say I'm keeping datetime variable in a session. Then, I want to
use it as a parameter in a datasource. But the variable in session will
be boxed to Object type, and I have no control on how datasource will
cast it - how can I prevent it from casting it to string and inserting
it into the query as a culture-unsafe string?
I think Select Parameters collection in Data Source properties might
help - after choosing session parameter I can show Advanced Properties
and change it's type (from string to datetime) - will Data Source use
this information to cast the session variable onto datetime properly?
2) dropdownlist values
I want to bind some datetime values to dropdownlist and use its
selected value as a control parameter of a data source. Does it mean,
that implicit toString conversion must happen during binding to ddl?
ddl.selectedValue has String type - does it mean, that everything bound
to ddl is converted to string - no way to prevent it? If it's true,
then how would it be done in case of datetime, which may be casted to
string in many different ways (because of formatting possibilities)?
Would standard datetime.toString() be used when populating ddl?
thanks a lot for any insight
cheers
HP