In this post:
I spent about 20 frustrating minutes the other day wondering why a sql
query wasn’t selecting the record I wanted. Everything looked right
until I stepped through my code the 3rd time. Then I discovered my
problem.
In a web form, I allow a user to select a row in a
GridView that fires an event to populate a DetailsView using an
ObjectDataSource. The select method of the ObjectDataSource takes two
parameters, a DateTime and a string. Since the date is coming from the
GridView, I was just using Convert.ToDateTime([date cell].ToString()).
I discovered that the DateTime displayed in the GridView was ‘5/21/2007 8:51:42 AM’ while the DateTime in the database was ‘2007-05-21 08:51:42.153’. They’re close, but not exactly the same. It’s that
missing fraction of a second that made my where clause incorrect.
So then I thought, “How can I successfully convert a DateTime to a string and back?” After a short pause it hit me, “Ticks”. No, not the kind of ticks I’m afraid of getting when backpacking in woods, but DateTime.Ticks. I used a HiddenField
to store the string representation of the selected DateTime in ticks,
and then added an overloaded select method that takes a ticks (long)
parameter. In the new method I simply construct a DateTime from the
ticks and call the original select method.
So in summary, to convert from DateTime to string and back, use ticks.