Назначение параметров запросу содержащемуся в SQL файле

← →
Тучудище (2005-05-24 08:31) [0]

Доброго времени суток уважаемые мастера!
Дело такое:
Есть некий файл Procedure.sql
Который содержит следующий запрос
SELECT ....... WHERE DateDoc BETWEEN :Param1 AND :Param2....
хотелось бы узнать, существует ли возможность назначить каким либо образом из Delphi эти самые :Param1 и :Param2
Заранее спасибо за ответ!

← →
DenK_vrtz © (2005-05-24 08:37) [1]

см. TParams

← →
Тучудище (2005-05-24 08:42) [2]

В самой программе св-во SQL у TQuery Выглядит так SELECT * FROM "Procedure.sql" так каким образом все таки можно этому Procedure.sql передать :Param1 и :Param2 на счет TParams понятно... но где??????

← →
DenK_vrtz © (2005-05-24 08:53) [3]

>но где??????

у TQuery свойство Params

← →
Тучудище (2005-05-24 09:00) [4]

Может я не догоняю что то, но каким образом в TQuery.Params могут попасть параметры из Procedure.SQL ведь сам TQuery.SQL имеет вид SELECT * FROM "Procedure.sql"...???

← →
atruhin © (2005-05-24 09:07) [5]

Сделай Prepare тогда Query распарсит файл и создаст параметры

← →
Sergey13 © (2005-05-24 09:15) [6]

Что за Procedure.sql? Какого он формата? Сколько в нем записей/команд?
Если ты делаешь SELECT * FROM "Procedure.sql" то стало быть потом идет выполнение содержащихся в файле запросов? Вот на этом этапе и надо присваивать значения параметрам.
Только нафига это все я не понял? Записей в Procedure.sql и количество параметров в них всегда одинаково?

← →
Тучудище (2005-05-24 09:29) [7]

Вот текст Procedure.sql

SELECT
Nomklat,
Sum(PrihRash) AS DebetCredit
FROM
PrihRash
WHERE
DateDoc BETWEEN :Param1 AND :Param2
GROUP BY Nomklat HAVING Sum (PrihRash)<>0

UNION ALL

SELECT
Nomklat,
Sum(Ostatok) AS DebetCredit
FROM
POstatki
WHERE
ActualDate:=Param1;
GROUP BY Nomklat HAVING Sum (Ostatok)<>0

Далее я вызываю пытаюсь выполнить запрос вида
SELECT Nomklat, SUM(DebetCredit) AS OstatokNaKonetz
FROM "Procedure.sql"
GROUP BY Nomklat HAVING SUM(DebetCredit)<>0
Собственно все замечательно, только вопрос стоит в том как передать этому Procedure.SQL Param1 и Param2

[5] спасибо за совет попробовал, но в момент TQuery.Prepare уже выдается сообщение "Parameter not set in query string"

← →
Тучудище (2005-05-24 09:32) [8]

[6]
Количество команд зашито жестко
Количество данных может изменяться
Делается все это для того, чтобы избежать(как мне кажется) лишних телодвижений с количеством запросов и сложных алгоритмов обработки данных

← →
Sergey13 © (2005-05-24 09:35) [9]

2[7] Тучудище (24.05.05 09:29)
Ты поступаешь в корне неправильно. Выкинь нафиг свой Procedure.sql - это тупик.

← →
Virgo_Style © (2005-05-24 09:36) [10]

Тучудище (24.05.05 9:32) [8]

А если сделать TQuery.SQL.LoadFromFile("procedure.sql"), а потом работать с TQuery.Params?

← →
msguns © (2005-05-24 09:37) [11]

А нельзя так:

with Query1 do
try
SQL.LoadFromFile("Procedure.sql");
Params[0].As... :=
Params[1].As... :=
Open;
except
ShowMessage("Shos probzdilo u datskomu korolivstvi");
end;

← →
ЮЮ © (2005-05-24 09:39) [12]

Procedure.sql - текстовый файл. Запиши его м нужными значениями, не параметрами.
Если клиент многопользовательский, то
1) уникальные имена для sql-файлов
2) + локальная БД и гетерогенные запросы

← →
ЮЮ © (2005-05-24 09:41) [13]

>[9] - [11]
Это подзапрос, а не полный запрос

← →
Sergey13 © (2005-05-24 09:41) [14]

Да у него ошибка не тут, а в
Далее я вызываю пытаюсь выполнить запрос вида SELECT Nomklat, SUM(DebetCredit) AS OstatokNaKonetz FROM "Procedure.sql" GROUP BY Nomklat HAVING SUM(DebetCredit)<>0

← →
msguns © (2005-05-24 09:48) [15]

А что, биде умеет работать с запросами
SELECT FROM (SELECT) ?

← →
Anatoly Podgoretsky © (2005-05-24 09:50) [16]

Через *.SQL

← →
ЮЮ © (2005-05-24 09:51) [17]

>Sergey13 © (24.05.05 09:41) [14]
и где ты тут ошибку видишь?

А вот параметры в запросе "Procedure.sql" использовать нельзя, т.к. текст должен содержать SQL предложение, а параметры - это уже фича от TQuery

← →
Тучудище (2005-05-24 09:53) [18]

[11] мне нужно получить результат запроса содержащегося в Procedure.sql и , чтобы не обрабатываеть его по тупому через
While not eof.... бла бла бла Next; выполнить к этому результату еще один запрос, делать результаты запроса permanent нет ни желания ни времени возиться с этим....

To all:
Может подскажите какой нибудь другой вариант?
Скажу что нужно,
1)Выполнить запрос № 1 из [7]
2)Обработать результаты запроса №1 запросом №2 из [7]
вот по сути и все...

← →
Anatoly Podgoretsky © (2005-05-24 09:57) [19]

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

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

← →
Тучудище (2005-05-24 09:58) [20]

Честно сказать, не проблема мне зашить этот запрос в таком виде как он должен быть, т.е. вместо Param1 и Param2 подставить конкретные числа... т.е. даты какая к черту разница, опасаюсь следующего
1) Поскольку доступ к БД многопользовательский, возможны колизии при обращении к этому файло...(доступ к данному механизму будет осуществлятся достаточно часто)
2) Возиться с разными именами файлов следить за уникальностью и т.п. ну честно ну ГЕМОРОЙ, должно быть простое решение суть в том что я пока не чую какое......

← →
Anatoly Podgoretsky © (2005-05-24 10:00) [21]

Ни каких колизий если этот файл будет на локальной машине. Соответственно пункт 2 исчезает.

← →
Виталий Панасенко (2005-05-24 10:02) [22]

1) Выполнить запрос №1
1.1) Определить тип(имена (не очень существенно)) полей, создать ВРЕМЕННУЮ таблицу с аналогичной структурой. Перегнать данные из запроса в таблицу
2)Обработать временную таблицу запросом №2

← →
Тучудище (2005-05-24 10:18) [23]

Вот в принципе суть проблемы может я и не оттуда начал,
Данный запрос
SELECT
Nomklat,
Sum(PrihRash) AS DebetCredit
FROM
PrihRash
WHERE
DateDoc BETWEEN :Param1 AND :Param2
GROUP BY Nomklat HAVING Sum (PrihRash)<>0

UNION ALL

SELECT
Nomklat,
Sum(Ostatok) AS DebetCredit
FROM
POstatki
WHERE
ActualDate:=Param1;
GROUP BY Nomklat HAVING Sum (Ostatok)<>0
возвращает именно в LOCAL SQL такую белеберду
я пробовал исполнять его на InterBase и MySQL все работает ок
возвращаемый набор данных
Tovar DebetCredit
1 70
123 60
132 90
500 2
700 6
При исполнении его же в Local SQL я получаю что то вроде
Tovar DebetCredit
1 100
1 -30
123 60
132 90
500 4
500 -2
700 6
Я думаю суть ясна... вот что конкретно побудило меня искать извращенные пути решения проблемы.... может кто то подскажет по каим принципам Local SQL делает UNION

← →
Sergey13 © (2005-05-24 10:37) [24]

2[17] ЮЮ © (24.05.05 09:51)
>и где ты тут ошибку видишь?
А можно селектить текст запроса?

← →
Val © (2005-05-24 10:44) [25]

>[24] Sergey13 © (24.05.05 10:37)
? см. local views в Local SQL Help.

> автору
лучший выход - действительно динамический sql.

← →
msguns © (2005-05-24 10:56) [26]

>Тучудище (24.05.05 10:18) [23]

Блин, до меня дошло !!!
Это он считает текущие остатки по складу. Как сумма сальдо на начало+движение.
Во-первых, и биде, и мускул возвращают правильные результаты, просто второй по умолчанию использует предикат DISTINCT, а второй - нет.
Во-вторых, ведь то же самое можно получить одним запросом безо всякого UNION, который в биде порождает парные записи.
В-третьих, вопрос: а зачем это надо-то ? А если нет таблицы текущих остатков (что при такой системе было бы разумно предположить), то как и где задается время остатка, в смысле точка сальдо (месяц-год, скорее всего) ?

ИМХО, что-то нездоровым запахло ;))

← →
Anatoly Podgoretsky © (2005-05-24 10:59) [27]

Виталий Панасенко (24.05.05 10:02) [22]
Именно это и делается с использованием файла *.SQL только автоматически.

← →
Sergey13 © (2005-05-24 11:01) [28]

2[25] Val © (24.05.05 10:44)
>? см. local views в Local SQL Help.
Хм. Действительно. Не знал. Лоханулся. Сори.

И еще в-четвертых: считается только кол-во ? Суммы джидаев не интересуют - не мелочны ?
В-пятых: все ж-таки неясно совершенно с этой загадочной таблицей остатков. Насколько я понял, она нужна для ускорения выполнения запросов подсчета кол-ва (сумм). Но почему в ней нет множественности по принципу сальдо по товару: Месяц: кол-во, сумма.
В шестых: а если по одному товару были разные приходы по разным учетным ценам и реализации по разныи отпускным ? Хотя, это уже суммовой учет, который, похоже, не для джидаев ;))

← →
Тучудище (2005-05-24 11:05) [30]

Поясню схему систему остатков реализую 2 таблицами
таблица 1:
Actions
Nomklat(Номенклатурник)
DebCred(Количество прихода расхода принимает значение -число +Число)
DateAct(Дата возникновения движения)
ну и некоторая служебная информация вроде тип документа и Ид документа
Таблица 2:
Period
Содержит
Nomklat(Номенклатурник)
DebCred(Количество остатка на конец периода)
Period - Это дата начала следующего месяца(01.XX.XX)
Что хочу от запроса, вынуть остаток на начало месяца
Прибавить к нему обороты за дату с 01.XX.XX по КонецМесяца.XX.XX
Тем самым вывести итог на 01.XX+1.XX но запрос порождает результаты о которых я говорил в [23] в следствии чего получаем на конец месяца какую то (извините) шнягу вместо путевых остатков не равных 0

>Sergey13 © (24.05.05 10:37) [24]
>А можно селектить текст запроса?

>Sergey13 © (24.05.05 11:01) [28]
>Хм. Действительно. Не знал. Лоханулся. Сори.

См. [15],[16]

ЗЫ. Невозможность конструкции SELECT FROM SELECT лично у меня сильно подорвало авторитет IB, не говоря уж о биде ;)

← →
Тучудище (2005-05-24 11:10) [32]

[29] суммовой учет не нужен абсолютно, учет ведеться только количественный, весь товар является не собственный и его цены ни кого не интересуют нужно знать только сколько его есть
На счет таблицы остатков совершенно верно нужно ускорить систему дабы остаток не считался по всем приходам и расходам, а была возможность взять сальдо на начало, прибавить обороты и тем самым получить сальдо на конец...

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

>Тучудище (24.05.05 11:05) [30]

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

>Тучудище (24.05.05 11:10) [32]
>суммовой учет не нужен абсолютно, учет ведеться только количественный,

Это кто так сказал - кладовщик Сеня ? Или уборщица Маша ? Или сторож Сан Саныч.
Глупости. Причем вовсе не ИМХО.

← →
Тучудище (2005-05-24 11:19) [36]

[34]
Если товар не двигался за этот период то его остаток есть на начало месяца в любом случае он попадает в итоги на конец месяца

Простой пример в этом месяце пришел товар 10 кол-вом 20
Остаток на конец периода 20
след месяц движений по товару 10 нет остаток на начало 20
получив остаток на начало периода прибавив обороты на конец получим остаток по товару 10 20 едениц.... он ползет из месяца в месяц....

Да, (actions) это детал по документам, но не фактура а абсолютно отдельная таблица (что то вроде регистра в 1Ц) при записи документа пользователем все необходимые данные по движениям добавляются в эту таблицу

← →
Тучудище (2005-05-24 11:21) [37]

[35]
Постановка задачи именно такая что суммовой учет никому не нужен

> а была возможность взять сальдо на начало, прибавить обороты
> и тем самым получить сальдо на конец...
- на начало уже хранили. Через год начнет притормаживать, через два тормозить, через три - будешь запускать ночные расчеты, так как при попытке посчитать текущий остаток система будет подвисать надолго.
Выход - остатки на конец. А остаток на начало любого периода можно пулучить минусуя приход и прибавляя расход. Так как обращения к недавним остаткам идет намного чаще, то это всех устроит. А если кому нибудь захочется посмотреть балланс за 3 года - его проблемы, пусть ждет.

>msguns © (24.05.05 11:06) [31]
>ЗЫ. Невозможность конструкции SELECT FROM SELECT лично у меня
>сильно подорвало авторитет IB, не говоря уж о биде ;)

Всегда есть обходные пути. Да и в FB2 она уже появилась.

← →
Тучудище (2005-05-24 11:37) [40]

Люди... собственно... чего с запросом то делать??? запрос левый или Local SQL левый???

Назначение параметров запросу содержащемуся в SQL файле Найти похожие ветки