Query SQL -запрос

← →
It06 (2004-10-02 11:09) [0]

Подскажите как в компоненте Query в SQL-запросе
подставить дату из компонента DateTimePicker
Перевожу дату в строку формат 10/10/2004

← →
DrPass © (2004-10-02 12:02) [1]

А может быть, надо 10.10.2004. А может быть, надо #10.10.2004#. А может быть, еще как-то надо. Какая у тебя СУБД, в конце-концов?

← →
Семен Сорокин © (2004-10-02 12:39) [2]

используй параметры
where datefileld = :mydate

ParamByName("mydate").AsDateTime := DateTimePicker1.Date;
Parameters.ParamByName("mydate").Value := DateTimePicker1.Date; {ADO}

← →
it06 (2004-10-02 12:49) [3]

Query.SQL.Add("Select * From Table Where DateFileld = (?)and DateFileld=(?)

← →
DrPass © (2004-10-02 15:20) [4]

Вот тебе посоветовали:
Query.SQL.Add("Select * From Table Where DateFileld = :date1 and DateFileld=:date2 "); Query1.Prepare; Query1.ParamByName("date1").AsDateTime := DateTimePicker1.Date; Query1.ParamByName("date2").AsDateTime := DateTimePicker2.Date;

← →
MaxDDinc (2004-10-03 17:14) [5]

Советовать можно много, как-то сам напоролся - надо было из БД ORACLE в INTERBASE все переложить ...
Предлагаю использовать для дат поле INTEGER, тогда для любой БД
приемлемо:
DataSource.FieldByName("MyDate").AsInteger:= Trunc(Now);
А потом можно и + и - и FormatDateTime ...

← →
sniknik © (2004-10-03 20:24) [6]

MaxDDinc (03.10.04 17:14) [5]
правильно. думай что сам советуеш, причем для всех баз сразу.
вот именно так, дату через интеджеп передавать... больше гарантий "напоротся"
проверь вот такой запрос в MSSQL, после говори о "правильности" для всех
SELECT Cast(:MyDate AS DateTime), :MyDate2
(первый параметр через интеджер передать, второй как положено дататайм)

нет общих решений, для всех, какими бы правильными они тебе не казались... пользоваться можно только стандартами, установленными спецификациями.
в IB сошлось похоже потому что борланд и его и дельфю разработал, стандарты совпали.
и кстати ты "напоролся" тебе ошибку выкинуло, правильно, а тут могут и не заметить(скорее всего, никаких же проявлений) что данные на пару дней различаются (особенно если не сегодняшнее пишут а перекладывают архивы).

← →
MaxDDinc (2004-10-03 21:43) [7]

sniknik (03.10.04 20:24) [6]
Я думаю, что советую ... И причем здесь "проверь такой запрос"
Я предложил использовать Int, а преобразовывать то, что вводит пользователь должно приложение, после чего сохранять в БД ...
Тем более, что разрабатывается приложение на Delphi.
Этот вариант пройдет и в MSSQL и в ORACLE, так как тип Int есть везде и, темболее, в InterBase.
Запрос необходимо составлять для поля Int, после чего в приложении отображать, как Str или Date

← →
MaxDDinc (2004-10-03 22:10) [8]

К примеру:
- в базе есть таблица MYPROTO с тремя полями:
ID INTEGER, DATE_INT INTEGER и PROTO_TXT VARCHAR[80];
- таблица хранит некий протокол определенных событий.
Необходимо выбрать события за определенные сутки. Работаем:
Пользователь:
- вводит дату через интерфейс программы в формате DateTime
Программа:
- перекодирует DateTime в Integer через Trunc(DateTime)
- формирует запрос:
Query.DasableControls;
Query.Active:= false;
Query.SQL.Clear;
Query.SQL.Add("select * from MYPROTO where DATE_INT = :DATE_INT");
Query.ParamByName("DATE_INT").AsInteger:= то самое преобразованное из DateTime в Integer;
Query.Active:= true;
Query.EnableControls;
В результате получаем, что требуется.

Если очень привязываться к платформе БД, то неминуемо наткнешься на проблему переноса всей БД на новую платформу, после чего придется править исходник в части содержащихся в нем запросов.

Удачи

Тогда возникает вполне логичный вопрос: а как в такой базе использовать консоль SQL? Или изначально предполагается, что не предусмотренные в клиентском софте операции выполняться и не должны?

← →
MaxDDinc (2004-10-03 22:25) [10]

Согласен, в моем предложении есть неудобство, так как я рассматривал вопрос со стороны приложения и только ...
Но если идет разработка весомого проекта, то для администрирования целевой БД можно придумать несколько утилит, так как в большинстве случаев, а то и всегда, нюансы БД знает только разработчик.
Хотя ... на вкус и цвет ... надо строить под задачу ...

> Этот вариант пройдет и в MSSQL и в ORACLE
не шути так.

> И причем здесь "проверь такой запрос"
притом, что это ответ (и проверка) почему нельзя интеджер использовать для передачи даты как минимум с одним SQL сервером.

> В результате получаем, что требуется.
в одном случае точно, на том сервере что у тебя, но без гаранитий на других.

теперь то что хотел показать (и что сам мог бы понять если бы проверил)
возьмем твое
Query.SQL.Add("select * from MYPROTO where DATE_INT = :DATE_INT");
Query.ParamByName("DATE_INT").AsInteger:= то самое преобразованное из DateTime в Integer;
то самое преобразование, сделанное в дельфях(!!!) Trunc(Now()) дает число 38264 для даты 04/10/2004 (сегодня).
это число уходит в запрос, и переобразуется назад к дате уже сервером (!!!), mssql сервером...
а вот сервер то его преобразует не к четвертому числу...
Cast(38264 AS DateTime) в MSSQL даст 06/10/2004 (послезавтра)
и спрашивается что мы получим? то что нужно? (ну это кому как, мне нужно 4-е)
(пример только для MSSQL(!!!) с установкой "точки отчета" с 01/01/1900 (это 0, у дельфей 0 в дате это 30/12/1899))
в итоге совпадет точка отчета получаем рабочий вариант нет трудноуловимую логическую ошибку (которую и видно не сразу если даты абстрактные (не сегодня к примеру)).

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

> Согласен, в моем предложении есть неудобство
называется оно глюк. если конечно не рассматривать как частный случай (но ты то позиционируеш наоборот типа для всех).
(а ну как завтра выйдет новый SQL сервер, с отсчетом по другому с 1900г? (ну покажется разработчикам что так лутше))

p.s. работаеш с одной базой, будь добр не тяни на другие ее (свои под нее) "предрассудки".

а..., до меня дошло ;о)) DATE_INT в базе! в самом поле тип. от оно как.

для всех... баз, ну да, ну да. берем парадокс, старый, тип инт (2байта, ну что делать еще во времена дос разрабатывался) максимальное значение 32767... сугодня уже 38264.

p.s. а см. предыдушее.

Query SQL -запрос Найти похожие ветки