Мужики, как в прямых запросах организуется такая конструкция: ВЫБОР КОГДА ТОГДА ИНАЧЕ?

Конкретно на примере:
   |    Журнал.DocNo as НомерДок,
   |   Журнал.IDDOC as Ссылочка,
   |   Журнал.DATE_TIME_IDDOC as ДатаДок,
   |   Журнал.SP1165 [Клиент $Справочник.Клиенты],
   |   $Док.Сумма as СуммаДокумента,
   |   Док.SP7090 as АлкИдентификатор
   |
   |FROM
   |   $Документ.ПриходныйКассовый as Док
   |INNER JOIN
   |    _1SJourn as Журнал
   |    ON Журнал.IDDoc = Док.IDDoc
   |WHERE
   |    CAST(LEFT(Журнал.DATE_TIME_IDDOC, 8) AS DATETIME) BETWEEN ? AND ?
   |GROUP BY
   |Журнал.IDDOC,
   |Док.SP7090,
   |Журнал.SP1165,
   |Журнал.DocNo,
   |Журнал.DATE_TIME_IDDOC,
   |$Док.Сумма
   |";

У док-та ПКО есть еще реквизит "ДатаПлатежа" Вот мне нужно так: Если этот ДатаПлатежа заполнен, тогда as ДатаДок(в запросе) равен ему, иначе он равен ДатаДок(документа). Какой конструкцией это организуется?

case
when /// then ///
when then
else
end

Учите уже T-SQL...

(1) Спасибо.
(2) Обязательно =)

|WHERE
|    Жур.Date_Time_IDDoc BETWEEN :ДатаНачала AND :ДатаОкончания~
|    AND Жур.Closed&1=1

>>
   |WHERE
   |    CAST(LEFT(Журнал.DATE_TIME_IDDOC, 8) AS DATETIME) BETWEEN ? AND ?

так делать нельзя! индекс не отрабатывает

+(1) И учитывай, что когда (в 1с, естественно!) поле типа дата не заполнено, то оно содержит не нулл, а 01.01.1753

(6) вот откуда, кстати? что такого эпического произошло в 18м веке? ;)

(7) Один Ес не осилило в 90-тые другого расчета дат :)

Интересно, а почему диапазон такой странный? Посмотрим-ка, как это выглядит в числах. -53690 и 2958463. Ничего особенного. Что же это за год такой знаменитый? Придется освежить свое знание истории. Вот, нашел. Англия, восточное побережье США, штаты Вашингтон и Орегон в 1752 году перешли с юлианского на григорианский календарь. Обидно за Техас, Неваду и Калифорнию, которые это сделали в 1582 году по примеру Испании, Италии, Португалии, Польши, Франции, Нидерландов.

ну и чо? восточное побережье - пуп земли?

(4) (5) Ага, исправил, спасибо.

(9)Даты

В SQL Server и дата и время хранятся в одном столбце, так что если с помощью функции GETDATE() запросить текущую дату, то при этом система сообщит и время. Для дат применяются два типа данных, datetime и smalldatetime. Тип данных smalldatetime охватывает период времени от 1 января 1900 года до 6 июня 2079 года и включает время с точностью до минуты. Такого диапазона достаточно для подавляющего большинства проектов. Тип данных datetime годен для использования до 31 декабря 9999 года (это следует учитывать при решении проблемы 10К года). Начало диапазона этого типа данных датируется 1 января 1753 года. Почему 1753? Это связано с переходом с юлианского на грегорианский календарь. Несмотря на то, что грегорианский календарь был предложен некоторое время назад, процесс его принятия продолжался в течение приблизительно 30 лет. На протяжении этого периода некоторые страны уже приняли грегорианский, а другие еще нет. Поэтому для того, чтобы дата воспринималась однозначно, надо знать географическое положение объекта. Кроме того, год начинался не 1 января, а 1 марта. Поэтому такая дата, как 15 января 1792 года, может интерпретироваться и как середина первого месяца 1492 года, и как середина 11-го месяца 1793 года. Создатели SQL Server решили не рисковать, и поэтому приняли решение не воспринимать даты, относящиеся к периоду времени до начала 1753 года. Следует отметить также, что тип данных datetime показывает тысячные доли секунды, хотя точность гарантируется только до 1/300 части секунды.
©

(9) Да просто дело не в 1С, а в SQL, это в нем даты начинаются от 1753 года, эска тут ни при чем совершенно

>Поэтому такая дата, как 15 января 1792 года
53го же. очепятки?

>середина первого месяца 1492 года
Тут вообще три столетия потеряли. Наверное действительно опечатки