Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 >
Тучудище © (2005-05-24 08:31:00)
Доброго времени суток уважаемые мастера!
Дело такое:
Есть некий файл Procedure.sql
Который содержит следующий запрос
SELECT ....... WHERE DateDoc BETWEEN :Param1 AND :Param2....
хотелось бы узнать, существует ли возможность назначить каким либо образом из Delphi эти самые :Param1 и :Param2
Заранее спасибо за ответ!

ЮЮ (2005-05-24 12:02:00) [21]
>В Local SQL INTO нетути.
зато есть
DELETE FROM
и
INSERT INTO ... SELECT ...

Тучудище (2005-05-24 11:53:00) [22]
[41] Задача такова, есть некая транспортная компания, которая перевозит грузы(легковые автомобили), собственнику фиолетово сколько эти грузы стоят, ему интересно сколько у нас этого груза на какой площадке и кому он пренадлежит, торговля тут свосем не при чем

msguns (2005-05-24 11:51:00) [23]
>Johnmen © (24.05.05 11:35) [39]
>Всегда есть обходные пути.

Да, но очень неудобно иногда по запросу, например
SELECT <много разных полей и выражений> FROM <куча всяких таблиц> WHERE <до фига условий и параметров>
построить запрос, для получения агрегатов по некоторым полям

>Да и в FB2 она уже появилась.
Слышал-слышал. Однако писать приложения (запросы) в расчете, что у клиента стоИт именно 2-й берд ?

>Тучудище (24.05.05 11:37) [40]
>Люди... собственно... чего с запросом то делать??? запрос левый или Local SQL левый???

Сказано ж было:
1.рисовать запрос динамически.
2.создавать и юзать временную таблицу

>ЮЮ © (24.05.05 11:43) [42]

В Local SQL INTO нетути.

ЮЮ (2005-05-24 11:43:00) [24]
см.[12] 2)
Кладешь ещё один TDataBase, его даже и настраивать особо не надо, только DataBaseName = local, т.е. та же папка где и ехе(если он локально лежит), или Alias ещё один сделай.

Теперь можешь делать гетерогенные запросы:

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
INTO ":local:temp"

или пару запросов, если temp.db нужной структуры существует и лежит в local
DELETE FROM ":local:temp"
INSER INTO ":local:temp"
SELECT ... и далее по тексту

В запросах можешь исользовать одновременно таблицы основной и локальной БД

msguns (2005-05-24 11:43:00) [25]
>Тучудище (24.05.05 11:19) [36]
>он ползет из месяца в месяц....

Во-во. При наличие неликвида (т.е.остатков, которые годами торчат, пока их не спишут или не сбагрят по дешевке) таких "пустых" записей в базе будет великое множество - см.ANB © (24.05.05 11:30) [38]
Что через какое-то время приведет к разбуханию таблиц и жутким тормозам.
Более того, для торговли, например, в опте, где большой ассортимент и офигенная оборачиваемость товара, КПД от такой базы будет крайне низкий. Т.е. такая система хранения и подсчета остатков есть нерациональная как минимум.

Кстати, неплохо бы хоть в общих чертах прояснить народу, чего учитываем-то, если цены и суммы по барабану ?
Надеюсь, не ядерные боеголовки ?

Тучудище (2005-05-24 11:37:00) [26]
Люди... собственно... чего с запросом то делать??? запрос левый или Local SQL левый???

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

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

ANB (2005-05-24 11:30:00) [28]

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

Тучудище (2005-05-24 11:21:00) [29]
[35]
Постановка задачи именно такая что суммовой учет никому не нужен

Тучудище (2005-05-24 11:19:00) [30]
[34]
Если товар не двигался за этот период то его остаток есть на начало месяца в любом случае он попадает в итоги на конец месяца

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

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

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

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

msguns (2005-05-24 11:12:00) [32]
>Тучудище (24.05.05 11:05) [30]

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

Anatoly Podgoretsky (2005-05-24 11:10:00) [33]
БДЕ по крайней мере дает хотя бы обходной путь, но и от него не следовало ожидать многого, это все таки не БД, а движок, а то что в него включили серверный интерпритатор, то это только плюс.
А вот на сервера имеет смысл обижаться.

Тучудище (2005-05-24 11:10:00) [34]
[29] суммовой учет не нужен абсолютно, учет ведеться только количественный, весь товар является не собственный и его цены ни кого не интересуют нужно знать только сколько его есть
На счет таблицы остатков совершенно верно нужно ускорить систему дабы остаток не считался по всем приходам и расходам, а была возможность взять сальдо на начало, прибавить обороты и тем самым получить сальдо на конец...

msguns (2005-05-24 11:06:00) [35]
>Sergey13 © (24.05.05 10:37) [24]
>А можно селектить текст запроса?

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

См. [15],[16]

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

Тучудище (2005-05-24 11:05:00) [36]
Поясню схему систему остатков реализую 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

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

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

Anatoly Podgoretsky (2005-05-24 10:59:00) [39]
Виталий Панасенко (24.05.05 10:02) [22]
Именно это и делается с использованием файла *.SQL только автоматически.

msguns (2005-05-24 10:56:00) [40]
>Тучудище (24.05.05 10:18) [23]

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

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

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »