.... where date between '20010618 00:00:00' and '20010618 23:59:59'

'20010618 00:00:00' - это символьное представление даты в формате yyyymmdd hh:mm:ss.

declare @d1 datetime, @d2 datetime
set @d1 = '20010618 13:00:00'
set @d2 = '20010618 16:35:35'

select .... where date between @d1 and @d2 ...

Чудес не бывает. Не может сравнение > работать, а < - не работать
Давайте уточним
- поле "DateUpdated" таблицы какого все же типа
- какого типа переменные startdate и endate, и как вы их инициализируете
- есть ли в таблице действительно данные с DateUpdate<endate

select * from sysobjects where crdate between '20010101 00:00:00' and '20010131 23:59:59'
select * from sysobjects where crdate > '20010101 00:00:00'
select * from sysobjects where crdate < '20010131 23:59:59'

Да резделитель даты # - это особенность Access-а, в MS SQL такого нет

VOPROS: vse dolgno b@t' zapisano tol'ko kak " 'yyyymmdd hh:mm:ss'" ili est' eshe kakieto vozmojnosti?

На конвертацию символьных представлений даты влияет установка сервера SET DATERORMAT в различных вариантах - mdy, dmy, ymd. Но мой вам совет: используйте yyyymmdd hh:mm:ss и вам не надо будет помнить о региональных установках.

2igor
select DISTINCT Owner_ID from Table where Date_Time between '20010101 00:00:00' and '20010131 23:59:59' order by Owner_ID

2АлексейК
Values with the datetime data type are stored internally by Microsoft SQL Server as two 4-byte integers. The first 4 bytes store the number of days before or after the base date, January 1, 1900 . The base date is the system reference date. Values for datetime earlier than January 1, 1753, are not permitted. The other 4 bytes store the time of day represented as the number of milliseconds after midnight.

2Igor
Все просто
- для точного сравнения строковых значений
select distinct insuredlastname, insuredfirstname, insuredid
from ericom_log
where entrytime between '20010101 00:00:00' and '20010131 23:59:59'
and insuredlastname = 'Ivanov'

- для сравнения на вхождение
select distinct insuredlastname, insuredfirstname, insuredid
from ericom_log
where entrytime between '20010101 00:00:00' and '20010131 23:59:59'
and insuredlastname LIKE '%Ivanov%'

маска для оператора LIKE имеет много вариантов, которые можно посмотреть в BOL

Поиск можно организовать через процедуру, которой будут передаватся пареметры поиска
Приблизительно так

CREATE PROCEDURE dbo.sp_Search1
@period_begin char(17),
@period_end char(17),
@insuredlastname varchar(50)=NULL,
@insuredfirstname varchar(50)=NULL
AS

SELECT distinct insuredlastname, insuredfirstname, insuredid
FROM ericom_log
WHERE entrytime BETWEEN @period_begin and @period_end
AND insuredlastname = ISNULL(@insuredlastname, insuredlastname)
AND insuredfirstname = ISNULL(@insuredfirstname, insuredfirstname)
GO

exec sp_sp_Search1 '20010101 00:00:00', '20010131 23:59:59', 'Ivanov'

exec sp_sp_Search1 '20010101 00:00:00', '20010131 23:59:59', default, 'Ivan'

exec sp_sp_Search1 '20010101 00:00:00', '20010131 23:59:59', 'Ivanov', 'Ivan'


Предложенный вариант очень приблизителен, т.к. многое будет зависеть от струтруры и объема ваших таблиц, наличия/отсутсвия индексов и общей концепции вашей системы.

ЗЫ
Моя личная иерархия
Чайник(dummy) - человек, несведующий в какой-либо области, признающий это и стремящийся научится (так что в общефилосовском смысле все мы (не)много чайники)

Ламер(lamer) - чайник, который не признает себя таковым и поэтому особо не стремящийся учится

Ламо(-) - ламер, считающий себя специалистом в какой-то области и пытающийся учить других

2RatTail
Не могу понять, кто конечный потребитель всех этих заморочек с датами? Это что, сидят тётки и QA пишут селекты

Все гораздо более прозаичней.
Клиентские приложения часто используют для передачи даты в процедуры не собственно тип дата(время) а преобразуют его в строку (наверное с целью не связыватся с определением параметров). Для такого преобразования часто используются функции данного приложения, которые могут преобразовывать дату в соответствии с региональными установками локальной машины. И вот "выяснение" - каким образом и во что была конвертирона дата - как раз может быть проблемой для sql сервера.
Поэтому IMHO гораздо проще договорится с разработчиками о конкретном формате представления типа дата(время) в символьных строках, во избежании авральных работ по изменению программ и процедур. Не факт, что это должен быть так рекомендуемый мной yyyymmdd hh:mm:ss (хотя я считаю его лучшим из-за того в том же CONVERT не нужно указывать дополнительо style), просто это должен быть формат удовлетворяющий и понятный всем.

2All
По поводу ника. В английской транскрипции он никак не связан с каким-либо именем собственным(напрямую разумеется)
http://dictionary.msn.com/find/entry.asp?search=glory
и поэтому не определяет мою половую принадлежность, а равно и мою сексуальную ориентацию.
За другие языки отвечать не могу
Хотя скрывать мне нечего - я мужеского полу (извините, если кого-нибудь разачаровал)