Question

I’ve got a timestamp column in SQL Server 2008.

Now I need to query that column by using a date that picks up from a calendar server control.

We assume that I got a DateTime dt object;

I need to filter by this datetime object that returns all the records logged on that date(dt).

   var a = DateTime.Now.ToString();
   var IsDone = from d in _le.diets
                 where d.log_time.Contains(a)
                 select d.done;

_le is a private entity framework object.

This code has problem:

Error 3 ‘byte[]’ does not contain a
definition for ‘Contains’ and the best
extension method overload
‘System.Linq.ParallelEnumerable.Contains(System.Linq.ParallelQuery,
TSource)’ has some invalid
arguments f:\tests\diet\diet\DataTier\DietMovieRepository.cs 30 32 diet

Error 2 Cannot convert lambda
expression to type ‘string’ because it
is not a delegate
type f:\tests\diet\diet\DataTier\DietMovieRepository.cs 30 26 diet

Error 1 Delegate
‘System.Func’
does not take 1
arguments f:\tests\diet\diet\DataTier\DietMovieRepository.cs 30 26 diet

Error 4 Instance argument: cannot
convert from ‘byte[]’ to
‘System.Linq.ParallelQuery’ f:\tests\diet\diet\DataTier\DietMovieRepository.cs 30 32 diet

I’m a EF beginner, thanks for your help!

UPDATE

IN EF cs file

I see

   public static diet Creatediet(global::System.Int64 id, global::System.Boolean done, global::System.Byte[] log_time)
        {
            diet diet = new diet();
            diet.id = id;
            diet.done = done;
            diet.log_time = log_time;
            return diet;
        }

Answer 1

A SQL Server “timestamp” has nothing to do with time (in fact the name “timestamp” is now marked deprecated; “rowversion” is identical and should be used instead).

If you truly have a “timestamp” this is not possible. If you have a datetime set to the insertion time, it should be trivial:

DateTime start = date.Date, end = start.AddDays(1);

...
where row.log_time >= start && row.log_time < end
...

Also, if you are mainly doing date-range searches, log_time may be a fair candidate for the clustered index. Or if you are doing day-based queries a non-clustered index on an integer that is the days-into-epoch would work too.