Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
Добрый день.
Есть вот-такой вот код
Выяснил, что в запросе, условие WHERE не проверяет условие sentDate >@current_unix_date
вопрос: почему и как это можно обойти?

DECLARE @current_unix_date  bigint
DECLARE @begin_unix_date bigint
DECLARE @current_unix_date_test bigint

set @current_unix_date = DATEDIFF(s, '19700101', GETDATE())
set @begin_unix_date = @current_unix_date-1000
set @current_unix_date_test= 1331903727980

SELECT [fromJID]as "отправитель"
      ,[toJID] as "получатель"
     ,DATEADD(s, sentDate/1000, '19700101') as "время"
     ,[body] as "текст"
      FROM [JABBER].[dbo].[ofMessageArchive]
      WHERE sentDate >@current_unix_date
18 мар 12, 18:29    [12269662]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Виталий из Петербурга
вопрос: почему и как это можно обойти?
Обходить нужно спереди. Потому что трамвай.
18 мар 12, 18:34    [12269683]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Winnipuh
Member [заблокирован]

Откуда: Київ
Сообщений: 10428
интересные у вас юникс даты...

@current_unix_date_test= 1331903727980
@current_unix_date = 1332084904
18 мар 12, 18:36    [12269690]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
Гавриленко Сергей Алексеевич,

Известно, что трамвай, нужно обходить спереди, потому, что вы не можете поместиться между двумя трамваями, ходящими в один ряд, и должны контролировать оба
А обычный транспорт может ходить в две и более полосы и его можно переждать на островке безопасности, поэтому нужно обходить сзади.

Видите, нубы везде больше вашего знают, Вы точно свою професию любите?
18 мар 12, 18:42    [12269721]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
Winnipuh
интересные у вас юникс даты...

@current_unix_date_test= 1331903727980
@current_unix_date = 1332084904


намек понял. спасибо большое
18 мар 12, 18:44    [12269735]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
Виталий из Петербурга
вопрос: почему и как это можно обойти?

Подход "мой код правильный, это ваш дурацкий сервер неправильно работает" так и остался выше моего понимания...
Глазками посмотрите на значения sentDate и @current_unix_date и все поймете.

ЗЫ: С дату надо хранить как дату, хотя бы в виде вычисляемого столбца. Тогда не будет таких дурацких проблем.
18 мар 12, 18:49    [12269752]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Виталий из Петербурга
Видите, нубы везде больше вашего знают, Вы точно свою професию любите?
Я вам рекомендую не оффтопить и задавать вопросы как следует, если вы любите свои темы.
18 мар 12, 18:51    [12269755]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
invm,

Да, спасибо большое мне уже выше все объяснили.
18 мар 12, 18:52    [12269761]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
invm,

Дело в том, что у меня в столбуе хранится Unixtime*1000, и если я буду преобразовывать каждую строку для сравнения, то объем вычислений буде увеличиваться. Мне не жалко (объем базы 1000 строк), но мне кажется это неправильным.
Т.е я предпочитаю привести к виду, используемому в базе, а потом уже сравнить.
18 мар 12, 19:02    [12269794]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
Winnipuh,
К сожалению, устранение ошибки дальше меня не подвинуло:
я домножаю отметки времени и интервалы на 1000 (для приведения к одному представлению), но дальше дело не идет

DECLARE @current_unix_date  bigint
DECLARE @begin_unix_date bigint
DECLARE @current_unix_date_test bigint

set @current_unix_date = DATEDIFF(s, '19700101', GETDATE())
set @begin_unix_date = (@current_unix_date*1000)-86400000
set @current_unix_date_test= 1331903727980

select @current_unix_date*1000
select @begin_unix_date

SELECT [fromJID]as "отправитель"
      ,[toJID] as "получатель"
      ,[sentDate] as "sentDate"
     ,DATEADD(s, sentDate/1000, '19700101') as "время"
     ,[body] as "текст"
      FROM [JABBER].[dbo].[ofMessageArchive]
      WHERE sentDate > @current_unix_date


Результат
1332096986000 \current
1332010586000 \begin

А сравнение так и не идет.
Куда можно смотреть (куда повставлять промежуточные) выводы для проверки?
18 мар 12, 19:07    [12269820]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
Виталий из Петербурга
invm,

Дело в том, что у меня в столбуе хранится Unixtime*1000, и если я буду преобразовывать каждую строку для сравнения, то объем вычислений буде увеличиваться. Мне не жалко (объем базы 1000 строк), но мне кажется это неправильным.
Т.е я предпочитаю привести к виду, используемому в базе, а потом уже сравнить.
А выбирать в запросе DATEADD(s, sentDate/1000, '19700101') as "время", это типа не вычисления? Почему не сделать так:
alter table [JABBER].[dbo].[ofMessageArchive] add sentDateAsDate as DATEADD(s, sentDate/1000, '19700101')
и не привести запрос к виду
SELECT [fromJID]as "отправитель"
      ,[toJID] as "получатель"
     ,sentDateAsDate as "время"
     ,[body] as "текст"
      FROM [JABBER].[dbo].[ofMessageArchive]
      WHERE sentDateAsDate > getdate()

Кстати, условие у вас странное, из серии "вперед в будущее".
18 мар 12, 19:22    [12269889]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
Виталий из Петербурга
А сравнение так и не идет.
Куда можно смотреть (куда повставлять промежуточные) выводы для проверки?
Выведите наконец данные в таблице и параметры поиска, и увидите ошибку.

Как можно вам помочь, если неизвестны данные???
18 мар 12, 19:30    [12269930]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
invm
Виталий из Петербурга
invm,

Дело в том, что у меня в столбуе хранится Unixtime*1000, и если я буду преобразовывать каждую строку для сравнения, то объем вычислений буде увеличиваться. Мне не жалко (объем базы 1000 строк), но мне кажется это неправильным.
Т.е я предпочитаю привести к виду, используемому в базе, а потом уже сравнить.
А выбирать в запросе DATEADD(s, sentDate/1000, '19700101') as "время", это типа не вычисления? Почему не сделать так:
alter table [JABBER].[dbo].[ofMessageArchive] add sentDateAsDate as DATEADD(s, sentDate/1000, '19700101')
и не привести запрос к виду
SELECT [fromJID]as "отправитель"
      ,[toJID] as "получатель"
     ,sentDateAsDate as "время"
     ,[body] as "текст"
      FROM [JABBER].[dbo].[ofMessageArchive]
      WHERE sentDateAsDate > getdate()

Кстати, условие у вас странное, из серии "вперед в будущее".


К вопросу об обработке в выборке: Операция над уже выбранными строками дешевле, чем операция над всеми столбцами

К вопросу о ALTER:Я не уверен, что наличие в таблице колонки лишнего столбца не помешает, той системе, которая пишет туда.

Кроме того, налицо проблема с оператором сравненияа не с получением данных из таблицы.
Т.е я или хочу странного лиюо записываю запрос неправильно (я догадываюсь, что у сервера с пониманием T-SQL все в порядке : ))
Если кто-то на форуме подскажет, как разобраться в "текущем селекте" будет хорошо

К вопросу о "назад в будущее": берем текущую дату (current), вычитаем константу (в данном случае-сутки), получаем значение начала выборки (begin). Начиная с этой даты и получаем отчет
18 мар 12, 19:44    [12269999]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
Виталий из Петербурга
Member

Откуда:
Сообщений: 55
alexeyvg,

Уже выводил (промежуточнные значения в моем посте есть).
1332099743000-конечное значение выборки (текущая дата)
1332013343000-начальное значение выборки (на 24 часа вперед)

Ниже выборка значений из столбца sentDate

1323765292950
1323765365615
1323765418624
1323765441619
1323765456517
1323876000775
1323876090382
1323876090522
1323876091052

Налицо то, что скрипт не сравнивает значение, т.е или select записан неправильно, либо ему отдается неправильное значение.
Как это понять?
18 мар 12, 19:48    [12270028]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31965
Виталий из Петербурга
alexeyvg,

Уже выводил (промежуточнные значения в моем посте есть).
1332099743000-конечное значение выборки (текущая дата)
1332013343000-начальное значение выборки (на 24 часа вперед)

Ниже выборка значений из столбца sentDate

1323765292950
1323765365615
1323765418624
1323765441619
1323765456517
1323876000775
1323876090382
1323876090522
1323876091052
Неправильно. Вы вывели не "конечное значение выборки", а конечное значение переменной * 1000. А сравниваете без * 1000

Выводите то, что используется в запросе, больше ничего не надо.
Виталий из Петербурга
Налицо то, что скрипт не сравнивает значение, т.е или select записан неправильно, либо ему отдается неправильное значение.
Как это понять?
Да, это надо понять так, что ему отдается неправильное значение, либо в таблице не те данные. которые вы ожидаете.

Неправильно тут нечего записывать, селект с одним условием :-)
18 мар 12, 20:01    [12270092]     Ответить | Цитировать Сообщить модератору
 Re: Помогите пожалуйста с запросом (на where не проверяется bigint)  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
Виталий из Петербурга
К вопросу об обработке в выборке: Операция над уже выбранными строками дешевле, чем операция над всеми столбцами

К вопросу о ALTER:Я не уверен, что наличие в таблице колонки лишнего столбца не помешает, той системе, которая пишет туда.
Т.е. вы спроектировали систему основываясь только на своих ощущениях. Хотите чесать левое ухо правой ногой -- дело ваше.

Виталий из Петербурга
Кроме того, налицо проблема с оператором сравненияа не с получением данных из таблицы.
Т.е я или хочу странного лиюо записываю запрос неправильно (я догадываюсь, что у сервера с пониманием T-SQL все в порядке : ))
Если кто-то на форуме подскажет, как разобраться в "текущем селекте" будет хорошо

К вопросу о "назад в будущее": берем текущую дату (current), вычитаем константу (в данном случае-сутки), получаем значение начала выборки (begin). Начиная с этой даты и получаем отчет
Нету никаких проблем с оператором сравнения. Вы используете в запросе @current_unix_date, которая есть просто getdate(), а вот @begin_unix_date вы не используете.
18 мар 12, 20:20    [12270173]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить