Глюки DateTime

← →
<Lelik> (2005-06-10 12:17) [0]

Я уже задавал этот вопрос
> Про DateTime (<Lelik> 03.06.05 17:44)

Думал, что проблема решена. Оказалось нет!
Суть в следующем:
выбираю из таблицы записи с датой создания позже, чем дата из параметра запроса:
SELECT * FROM gpv_changes WHERE change_time > :lasttime
change_time - тип datetime default = GETDATE()
Parameters.ParamByName("lasttime").DataType := ftDateTime; Parameters.ParamByName("lasttime").Value := ATime;
ATime - тип datetime
В доп. потоке считываются данные из таблицы gpv_changes, где
change_time > ATime
После этого ATime присваивается время последней считанной записи.
По идее в следующем цикле должны считаться только более ранние записи по сравнению с ATime. Но в результирующий набор включается и строка, где change_time = ATime.
Использую посоветованные мне методы отлова с пом. datetimetostring и floatotstr дали след. рез-ты:
s1 := floattostr(ATime); s5 := floattostr(FieldByName("change_time").AsDateTime); datetimetostring(s3,"yyyymmdd hh:nn:ss:zzz",ATime); datetimetostring(s4,"yyyymmdd hh:nn:ss:zzz",FieldByName("change_time").AsDateTime);
s1 = "38513,4820303588"
s5 = "38513,4820303588"
s3 = "20050610 11:34:07:423"
s4 = "20050610 11:34:07:423"
В рез. набор попала лишняя запись.
Стал смотреть через Query Analyzer
select cast(38513.4820303588 as datetime) select change_time from gpv_changes select cast(change_time as float) from gpv_changes
Получил:
2005-06-12 11:34:07.420
2005-06-10 11:34:07.423
38511.482030362655
Это чтож получается.
Delphi представляет s1 как s3. Посылает это дело на сервер.
А сервер из *.423 делает *.420. Где логика.
Помогите пожалуйста разобраться!

← →
Seg (2005-06-10 12:21) [1]

Попробуй послать на сервер параметр ввиде строки, а не в виде даты.

← →
-=XP=- © (2005-06-10 12:28) [2]

У Вас с БД работает несколько пользователей на разных компьютерах?

← →
<Lelik> (2005-06-10 12:39) [3]

2 -=XP=- ©
Пока с БД я работаю один, в дальнейшем - порядка 100 человек.

← →
-=XP=- © (2005-06-10 12:44) [4]

Я так понял, у Вас проблема в этом:

2005-06-10 11:34:07.420
2005-06-10 11:34:07.423

Вы уверены, что у всех пользователей на компьютерах время будет синхронизировано с такой точностью?

Я рекомендовал бы не использовать в данном случае временной штамп, а создать автоинкрементное поле, и работать с ним. Запоминать значение этого поля при обновлении, и выбирать в следующий раз записи с значением этого поля больше последнего.

← →
<Lelik> (2005-06-10 12:55) [5]

2 -=XP=- ©
>Вы уверены, что у всех пользователей на компьютерах время будет синхронизировано с такой точностью?

Мне кажется здесь проблем быть не должно, ведь время в клиентской части не влияет. Из базы считываются записи. Время последней передается клиенту. Затем этоже время используется как параметр в запросе на выборку более ранних записей.
Т.е. я получаю переменную типа DateTime, а потом использую ее в запросе как параметр.

>Я рекомендовал бы не использовать в данном случае временной штамп, а создать автоинкрементное поле, и работать с ним. Запоминать значение этого поля при обновлении, и выбирать в следующий раз записи с значением этого поля больше последнего.

Да, это было бы хорошим решением. Но дело в том, что в таблице записи будут периодически удалятся по дате. Например, старше чем 60 сек.
DELETE FROM [dbo].[gpv_changes] WHERE DATEDIFF(ss, [change_time], GETDATE()) > 60

← →
Stanislav © (2005-06-10 13:22) [6]

2005-06-12 11:34:07.420
2005-06-10 11:34:07.423
38511.482030362655
Здесь вообще-то и числа разные !

← →
-=XP=- © (2005-06-10 13:22) [7]

Но дело в том, что в таблице записи будут периодически удалятся по дате

Кем? Если клиентом, то при каждом удалении (как там, раз в 60 секунд) запоминайте значение автоинкрементного поля наиболее ранней оставшейся записи, и при послепоследующем :) удалении пользуйтесь им как отправной точкой. А факт удаления старых записей на выборку последующих записей уже влиять не будет.

Мое мнение: В системах синхронизации данных не стоит привязываться к времени. Мало ли что может произойти - то ли на разных компьютерах время разное, то ли сервер БД решил засинхронизироваться с сервером времени в интернете, и получился сдвиг не несколько секунд/минут, то ли администратор сервера решил что-то там настроить, и перевел дату на год вперед. Всякое бывает. А описывать в мануале требования к точности времени - так их никто не читает.

Да и выборка по автоинкрементному полю (целые последовательные числа) будет гораздо быстрее, чем по полю дата/время (числа с плавающей запятой).

← →
-=XP=- © (2005-06-10 13:23) [8]

Здесь вообще-то и числа разные!

Лично я воспринял это как опечатку ;)

← →
<Lelik> (2005-06-10 13:34) [9]

2 Stanislav ©
> Здесь вообще-то и числа разные!
2 -=XP=- ©
> Лично я воспринял это как опечатку ;)

Все просто: первая дата получена на основе даты Delphi,
вторая - SQLServer. Разница - 2 дня.
Отличие - в стартовой дате (12/30/1899 - Delphi) и (01/01/1900 для MSSQL).
А насчет времени и автоинкремента - спасибо. Про всякие администраторские штучки как-то не подумал. Однозначно привязка будет другая.
Спасибо!

← →
Stanislav © (2005-06-10 13:36) [10]

А это все из-за того что представление даты у SQL SERVER и у DELPHI разные, а дату нужно передавать в строковом формате, а не в формате float.

← →
Anatoly Podgoretsky © (2005-06-10 13:49) [11]

Больше так не делай, не надо делать приведение, у Борланда формат даты не совпадает, всегда используй параметры типа TDateTime

← →
<Lelik> (2005-06-10 13:55) [12]

2 Anatoly Podgoretsky ©

Про какое приведение идет речь?
И каие еще несовпадения дат у Борланда?
И в самом начале я привел пример, что использую параметр типа datetime. А все остальные преобразования datetimetostring и floattostr - так это только чтоб посмотреть.

select cast(38513.4820303588 as datetime)
select change_time from gpv_changes
select cast(change_time as float) from gpv_changes
Получил:
2005-06-12 11:34:07.420 - это формат Борланда
2005-06-10 11:34:07.423 - это формат Микрософта
38511.482030362655 - это формат Микрософта
Не смешивай их никогда

Еще, глюков нет, только у тебя в голове.

-=XP=- © (10.06.05 13:22) [7]
Да и выборка по автоинкрементному полю (целые последовательные числа) будет гораздо быстрее, чем по полю дата/время (числа с плавающей запятой).

Неверно по сути, для этой цели существует исключительно тип TIME_STAMP, по новому ROWVERSION

Удалено модератором

Глюки DateTime Найти похожие ветки